Everything posted by box01
-
Some disks in RaidZ2 become UNAVAIL after New Config
It spent several hours trying to find the array, and I eventually decided it wasn't worth it, most of the data was in other places. Individual files from the disks weren't recoverable either - probably because of data stripe. Well, for the future, I guess I shouldn't store everything in one zfs array, but give some of the disks to "flat" backup.
-
Some disks in RaidZ2 become UNAVAIL after New Config
root@elvinhome:~# zdb -l /dev/sdi1 failed to unpack label 0 failed to unpack label 1 failed to unpack label 2 failed to unpack label 3
-
Some disks in RaidZ2 become UNAVAIL after New Config
Thank you, I'll try it when the ufs explorer finishes its work :)
-
Some disks in RaidZ2 become UNAVAIL after New Config
I was hoping that this was some known and preferably reversible glitch. Well, thanks for the help anyway! Maybe it would be possible to, say, create the same partition as on "healthy" disks? So that only the header would be rewritten - if such a concept is applicable...
-
Some disks in RaidZ2 become UNAVAIL after New Config
When I started the array after new config , the GUI showed about a hundred writes for each disk. It was fast, so it's unlikely that much was rewritten. Maybe some partition headers or else. Welcome to sfdisk (util-linux 2.41). Changes will remain in memory only, until you decide to write them. Be careful before using the write command. Checking that no-one is using this disk right now ... OK Disk /dev/sdi: 9.1 TiB, 10000831348736 bytes, 19532873728 sectors Disk model: WDC WD102KRYZ-01 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes sfdisk is going to create a new 'dos' disk label. Use 'label: <name>' before you define a first partition to override the default. Type 'help' to get more information. >>> 64 The size of this disk is 9.1 TiB (10000831348736 bytes). DOS partition table format cannot be used on drives for volumes larger than 2199023255040 bytes for 512-byte sectors. Use GUID partition table format (GPT). Created a new DOS (MBR) disklabel with disk identifier 0xcf93c739. Created a new partition 1 of type 'Linux' and of size 2 TiB. /dev/sdi1 : 64 4294967295 (2T) Linux /dev/sdi2:
-
Some disks in RaidZ2 become UNAVAIL after New Config
Yes, these 4 disks reported as no partitions in GUI Disk /dev/sdi: 9.1 TiB, 10000831348736 bytes, 19532873728 sectors Disk model: WDC WD102KRYZ-01 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes
-
Some disks in RaidZ2 become UNAVAIL after New Config
elvinhome-diagnostics-20250908-1809.zip
-
Some disks in RaidZ2 become UNAVAIL after New Config
Hi. I decided to change some SATA cables on my 7-disk raidz2 array. At the same time, I reconnected some disks to other connectors. After loading, Unriad could not start the array, it wrote Unmountable: wrong or no file system. At the same time, the array was imported by the zpool import command, although it was mounted in shares. The files were in place through the explorer. I decided to create a New Config in order to import it through the interface (I had succeeded with another array before). Apparently, I made two mistakes. I did not select the None option, that is, the array remained in the interface. The second mistake - I launched this array as is, without looking at the properties. It turned out that the file system was reset to Auto in the properties. As a result, the array did not start, and zpool import displays the UNAVAIL status for 4 of the 7 disks (the other 3 are ONLINE). Accordingly, the array is not imported through the command line either. In the Unriad interface, these disks are visible as No partition. It looks like Unraid wrote something to these four disks and erased the partition information. Is there any way to restore the array?