project6

Yeah, my newest drive is xfs but this one became reiserfs again, I won't bother changing it now. Most of the stuff on here is archived stuff anyway. I looked at some files before formatting and it looked OK. Some folders are already copied back over and those files are working as expected. I'm copying the rest now. Will be interesting to see if anything fails as the disks fills up again, hopefully not. I also went over all split levels and allocation methods on all shares just to be sure and put them at safe values. Thanks a lot for your help on this issue @JorgeB, very very helpful and guiding with commands! I will write down a summary of the process in my main post if anyone else finds themselves in the situation of a 100% full disk and unable to check/fix the file system. Keep up the good work!

Yeah, thanks, that seems like a safe way to do it. Format in progress!

Yeah, it works.

Ok wow, that was a lengthy operation. The rebulding has finished now, so I assume I have a working reiser file system on the external drive. The million dollar question now is how do I get this baby: Disk /dev/sda: 3.65 TiB, 4000787029504 bytes, 7814037167 sectors Disk model: Expansion Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: 85A3F82A-B297-4615-BAAD-A493C44D51D3 Device Start End Sectors Size Type /dev/sda1 64 7814037133 7814037070 3.7T Linux filesystem back to this baby: Disk /dev/sdh: 1.84 TiB, 2000398934016 bytes, 3907029168 sectors Disk model: ST2000DM001-1ER1 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: dos Disk identifier: 0x00000000 Device Boot Start End Sectors Size Id Type /dev/sdh1 64 3907029167 3907029104 1.8T 83 Linux Without messing anything up. I'm not sure I have the time to re-do the dd and rebuilding operation one more time 😀

Managed to create a partition now, sb rebuilt... now running rebuild-tree. Rebuilding takes alot longer now, which is a good sign I guess since that means it's using the entire disk and probably won't exit with out of space error.

Still no partition on it and same output from sgdisk

Ok, the sgdisk command didn't go through. I deleted the partition using fdisk to try and recreate it but It's not working: sgdisk -o -a 8 -n 1:32K:0 /dev/sdh gives Invalid partition data! Information: Creating fresh partition table; will override earlier problems! The operation has completed successfully. But no visible partition afterwards.

Ok, gotcha. Looking with fdisk on the device itself makes a lot more sense, it indeed has a partition that will hopefully be transferred to the external drive now! Disk /dev/sdg: 1.84 TiB, 2000398934016 bytes, 3907029168 sectors Disk model: ST2000DM001-1ER1 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: dos Disk identifier: 0x00000000 Device Boot Start End Sectors Size Id Type /dev/sdg1 64 3907029167 3907029104 1.8T 83 Linux So after dd finished, I delete the 1.8T partition on the extension disk, re-create one with same start but full size, then rebuild-tree. Fingers crossed!

Damnit, I'm aborting the reiserfsck then and re-doing the dd with the disk as input... I ran the initial reiserfsck --rebuild-tree on /dev/md3 as well. Maybe this could've been fixed simply running it on the partition on /dev/sdg instead? Do you think I should try that first?

Thank you. Partitioned created, superblock rebuilt and now waiting for the rebuild-tree to finish. Just a thought: I did the dd from the raid device (/dev/md3) to the extension disk, should I have done it from the actual disk (/dev/sdg) instead?

Hmm I am unable to create a partition starting on sector 64, 2048 is the minimum: Command (m for help): n Partition type p primary (0 primary, 0 extended, 4 free) e extended (container for logical partitions) Select (default p): Using default response p. Partition number (1-4, default 1): First sector (2048-4294967295, default 2048): 64 Value out of range.

Ok, I removed the out-of-the-box partitions and completely wiped the extension disk and have now re-cloned the 2TB disk onto it. However, neither the original 2 TB disk (/dev/md3) or the 4 TB extension (/dev/sdh) have any partitions as far as I can tell: Disk /dev/md3: 1.84 TiB, 2000398901248 bytes, 3907029104 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/sdh: 3.65 TiB, 4000787029504 bytes, 7814037167 sectors Disk model: Expansion Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Should I create a partition on the external drive or just go ahead and run reiserfsck as it is currently?

Ok, what is the preferred way to completely wipe a disk in Unraid? Should my dd command target the entire disk then? Like so if=/dev/md3 of=/dev/sdh or should I set up a partition on it and use that as a dd target?

Ok, looking for some more guidance on this, I'm not very familiar with partitioning Unix devices. The external drive I used as target for the dd operation (/dev/sdh) seems to have come with some prepared partition that is already set to pretty much the entire drive (sdh2). Though the type is Microsoft basic data, so I guess it's prepared for Windows. The dd operation was successful in cloning to it though. Disk /dev/sdh: 3.65 TiB, 4000787029504 bytes, 7814037167 sectors Disk model: Expansion Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: 94AC4C02-F4C0-4043-8C43-037A0A2B3841 Device Start End Sectors Size Type /dev/sdh1 34 262177 262144 128M Microsoft reserved /dev/sdh2 264192 7814035455 7813771264 3.7T Microsoft basic data Partition 1 does not start on physical sector boundary. So should I delete the partition sdh2 and re-create it? Will it make any difference, as it's already of max capacity? Just for the fun of it I tried the reiserfsck rebuild command on the current sdh2, it corrected and fixed the same stuff as on the original 2TB disk and eventually ended up failing with not enough free space.

I also stumbled upon the resizepart -command; looking back, would it perhaps have worked to simply run this on the partition that showed the wrong size to force Unraid to treat it as 2 TB instead of 17.6 TB?

Ok, not sure how I do that. Googled and found resize_reiserfs. So In my case the partition is currently 4 TB and I want it to be 2 TB, so something like: resize_reiserfs -s 2000G /dev/sdh2 Would that make sense?

Disk cloning is now in progress, to an external 4 TB drive. Once this is done, do I simply run the reiserfsck command again (with --rebuild-tree) on the cloned device and let it finish? And then, in theory, I have the disk with filesystem "back" but on another disk, and I somehow need to shrink it to make it fit on the 2 TB drive again, right?

Thanks, split level looks good as well.

Yeah, I appreciate the info, but all my shares have include all exclude none, and have always been like that. This is not a configuration issue, it would've surfaced much earlier. If I were to guess, "something" happened with disk3 that caused free space to jump from almost nothing to 17.6 TB (as in the screen shot), then Unraid pushed new data onto it despite it being full. I can't say what caused it since I was not home at the time, I just received 100% full alerts on my mail all of a sudden. My priority now is to save the data but it would be nice if Unraid could identify this mismatch in free space (I guess Unraid has metadata about the disk that shows the drive as 2 TB, so it should never be able to have 17.6 TB free) and maybe instead default to zero free or something.

Yeah, I have not modified anything like that and 236 GB have been written to disk4 over the last few months so It has worked fine, until "something" happened. Very strange.

Thanks for info. I'm gonna try tomorrow, gonna do the dd command first since that seems fairly straight forward (making sure the correct target device is selected ). Do I need to format the external HD before running dd, if so should I format it as reiserfs then? I'm not sure I want to include it to the Unraid array, just want it as a temporary clone target. I'm probably gonna go with a 4 TB drive.

Sounds like a plan. Can I use an external USB HD as a clone target? I don't think my cabinet has any more free SATA connectors, and 2TB is max/partition drive size.

Thanks for info, I have not done any change to shares regarding this, it's all been the same pretty much since the day I built the machine. That is many, many years ago. Allocation is set to High water and minimum free, can't even remember I ever touched this setting, seems to be 0KB on all my shares. Starting with a single drive probably ten years ago I'm now up to four and have not had this issue before, allocation has always been nicely spread out. Maybe I've just been lucky until now then. So just to clarify so I understand this correctly, Unraid choose to keep writing to disk3, being close to max capacity, although it had disk4 available which only used 200 MB of 2TB. And to stop that I would have to set a minimum free for all shares? Is there any way the data on the disk can be saved at all, can I replace the slot with a new disk now or is it lost? The largest files on the drives are around 1-2 GB.

I have other disks with plenty of space, previously when a disk started filling up Unraid always put new data on the other disks. So I'm not sure why it kept putting it on disk3, I assume since it found 17.6 TB free.

Yes, I got alerts a couple of days ago that disk3 was low on space (100%) so it is probably full. When I got home a few days later I looked at the UI and found the `nan B` used and mover beeing stuck/hanged.