project6 Posted November 19, 2020 Author Share Posted November 19, 2020 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. Quote Link to comment
trurl Posted November 19, 2020 Share Posted November 19, 2020 41 minutes ago, project6 said: not modified anything like that and 236 GB have been written to disk4 Note that the settings I mentioned are per user share. Just because some user shares were able to write to disk4 doesn't mean others weren't configured in such a way to prevent them from doing so. Quote Link to comment
project6 Posted November 19, 2020 Author Share Posted November 19, 2020 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. Quote Link to comment
trurl Posted November 19, 2020 Share Posted November 19, 2020 44 minutes ago, project6 said: all my shares have include all exclude none Split level has precedence over allocation method Quote Link to comment
project6 Posted November 20, 2020 Author Share Posted November 20, 2020 12 hours ago, trurl said: Split level has precedence over allocation method Thanks, split level looks good as well. Quote Link to comment
project6 Posted November 20, 2020 Author Share Posted November 20, 2020 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? Quote Link to comment
JorgeB Posted November 20, 2020 Share Posted November 20, 2020 16 minutes ago, project6 said: do I simply run the reiserfsck command again (with --rebuild-tree) on the cloned device and let it finish? You need to resize the partition first. Quote Link to comment
project6 Posted November 20, 2020 Author Share Posted November 20, 2020 1 hour ago, JorgeB said: You need to resize the partition first. 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? Quote Link to comment
project6 Posted November 20, 2020 Author Share Posted November 20, 2020 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? Quote Link to comment
JorgeB Posted November 20, 2020 Share Posted November 20, 2020 Unlikely that any filesystem resize will work due to being damaged, you can resize the partition by creating a new one on top of the existing one, same start sector but using the full disk. 1 Quote Link to comment
project6 Posted November 22, 2020 Author Share Posted November 22, 2020 (edited) 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. Edited November 22, 2020 by project6 Quote Link to comment
JorgeB Posted November 22, 2020 Share Posted November 22, 2020 That's not a linux partition, dd should have overwritten any existing paritition(s), though since a 2TB disk will be MBR it might be using the backup GPT, suggest you completely wipe that disk and delete all partitions, then re-run dd, also make sure you're using the correct target. Quote Link to comment
project6 Posted November 22, 2020 Author Share Posted November 22, 2020 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? Quote Link to comment
JorgeB Posted November 22, 2020 Share Posted November 22, 2020 Yes, you should use the device, it's also possible it's still using the old layout, try rebooting first. Quote Link to comment
project6 Posted November 23, 2020 Author Share Posted November 23, 2020 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? Quote Link to comment
JorgeB Posted November 23, 2020 Share Posted November 23, 2020 That's weird, create a new partition on the USB disk starting on sector 64, then rebuild the reiser superblock, then run --rebuild-tree. Quote Link to comment
project6 Posted November 23, 2020 Author Share Posted November 23, 2020 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. Quote Link to comment
JorgeB Posted November 24, 2020 Share Posted November 24, 2020 You can use this: sgdisk -o -a 8 -n 1:32K:0 /dev/sdX Quote Link to comment
JorgeB Posted November 24, 2020 Share Posted November 24, 2020 Also don't forget that you'll then need to always run reiserfsck on the partition, not the disk, always /dev/sdX1 never /dev/sdX Quote Link to comment
project6 Posted November 24, 2020 Author Share Posted November 24, 2020 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? Quote Link to comment
JorgeB Posted November 24, 2020 Share Posted November 24, 2020 1 hour ago, project6 said: should I have done it from the actual disk (/dev/sdg) instead? Yes!!! That explains the missing partition. Quote Link to comment
project6 Posted November 24, 2020 Author Share Posted November 24, 2020 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? Quote Link to comment
JorgeB Posted November 24, 2020 Share Posted November 24, 2020 1 minute ago, project6 said: I ran the initial reiserfsck --rebuild-tree on /dev/md3 as well. That is correct, when running on an array device you always use the md device to maintain parity, since the md device is the partition no need to specify it, when running on a device outside the array you need to use the sdX device and always specify the partition. 1 Quote Link to comment
project6 Posted November 24, 2020 Author Share Posted November 24, 2020 Just now, JorgeB said: That is correct, when running on an array device you always use the md device to maintain parity, since the md device is the partition no need to specify it, when running on a device outside the array you need to use the sdX device and always specify the partition. 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! Quote Link to comment
JorgeB Posted November 24, 2020 Share Posted November 24, 2020 2 minutes ago, project6 said: I delete the 1.8T partition on the extension disk No need to delete just create a new one on top, also best to rebuild the super block if not pretty sure it won't use the extra size. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.