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.

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.

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.

44 minutes ago, project6 said:

all my shares have include all exclude none

Split level has precedence over allocation method

12 hours ago, trurl said:

Split level has precedence over allocation method

Thanks, split level looks good as well.

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?

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.

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?

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?

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.

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, 20205 yr by project6

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.

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?

Yes, you should use the device, it's also possible it's still using the old layout, try rebooting first.

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?

That's weird, create a new partition on the USB disk starting on sector 64, then rebuild the reiser superblock, then run --rebuild-tree.

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.

 

You can use this:

sgdisk -o -a 8 -n 1:32K:0 /dev/sdX

 

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

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?

1 hour ago, project6 said:

should I have done it from the actual disk (/dev/sdg) instead?

Yes!!! That explains the missing partition.

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?

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.

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!

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.