Alright, I just updated to 6.2.0-RC5. What should I do now?

You can try to expand the partition, don't know if it will work on a corrupted filesystem.

 

sfdisk /dev/sdX

 

X = cloned disk

 

Look at the starting sector of current partition and use the same number to create a new one using the full size, e.g., if it's 64 type 64 and press enter.

 

Then type write and enter to apply changes.

 

Finally:

 

resize_reiserfs /dev/sdX1

 

If the resize succeeds run reiserfsck again, if it fails you can try the disk rebuild.

 

Any doubts ask

I am getting an error:

 

# sfdisk /dev/sdc1 
/dev/sdc1: device contains a valid 'reiserfs' signature; it is strongly recommended to wipe the device with wipefs( if this is unexpected, in order to avoid possible collisions

Welcome to sfdisk (util-linux 2.27.1).
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 ... FAILED

This disk is currently in use - repartitioning is probably a bad idea.
Umount all file systems, and swapoff all swap partitions on this disk.
Use the --no-reread flag to suppress this check.

sfdisk: Use the --force flag to overrule all checks.

Disk can't be in use, reboot if it shouldn't be.

And make sure you're doing it on the  right disk, identity can change with reboot, etc.

No, it is the right disk and rebooting didn't fix this either.

You can't use sfdisk while the disk is being used.

Ok, how am i using it?

Checking that no-one is using this disk right now ... FAILED

 

This disk is currently in use - repartitioning is probably a bad idea.

Umount all file systems, and swapoff all swap partitions on this disk.

Use the --no-reread flag to suppress this check.

 

Something is using it.

I have no idea what that could be. Can you help me find out?

Don't know the best command for that, maybe someone else will pitch in.

But I cant do the same thing with sfdisk installed on 6.1.9? I didn't have this issue there.

Looks like sfdisk on v6.1.9 does not correctly detect GPT partitions, so it won't work.

 

Try booting 6.2 using safe mode, make sure the array is stopped, and try again, if it sill doesn't work I'm out of ideas.

How can I boot in safe mode?

2nd option:

 

I dont have a screen attached to my server. is there another way?

on the wegGUI, click on the flash drive, Syslinux configuration will look similar to this:

 

 

default /syslinux/menu.c32

menu title Lime Technology, Inc.

prompt 0

timeout 50

label unRAID OS

  menu default

  kernel /bzimage

  append pci-stub.ids=8086:10d3 pcie_acs_override=downstream initrd=/bzroot

label unRAID OS GUI Mode

  kernel /bzimage

  append initrd=/bzroot,/bzroot-gui

label unRAID OS Safe Mode (no plugins, no GUI)

  kernel /bzimage

  append initrd=/bzroot unraidsafemode

label Memtest86+

  kernel /memtest

 

Move the highlighted "menu default" below the safe mode option.

Ok, I am getting the same error in safe mode...

Then try the rebuild option, I'm going to try that myself on a friend with the same issue, since is parity is already larger.

Do you mean just running

reiserfsck --rebuild-tree

Or are you talking about something else? Did it help your friend?

I meant try to rebuild to a bigger disk, like RobJ suggested, you need to upgrade your parity first.

 

My friend had a different issue, he told me that reiserfsck was aborting with a out of space error, turns out it was out of memory error, he only had 2GB, I upgraded his server to 4GB and reiserfsck completed.

I copied my data from a 3TB drive to a 4TB drive.

 

Do you mean rebuilding my unRAID array or the file system?

There's a way, but I don't think you are going to like it!  Replace that 3TB drive with a 4TB drive.  But that means having to replace the parity drive too, so you will have to buy 2 4TB or larger drives.  You would have to first rebuild parity with a larger drive, then rebuild Disk 1 onto a larger drive, then try reiserfsck with the --rebuild-tree option again.  I don't know if that's possible for you, but I can't think of any other ideas.  Unless reiserfsck can finish sufficiently to build a root block and superblock, you can't mount the drive to copy stuff off.

Ok, and that will work? The next comment suggests that it doesn't.

 

Not sure that idea will work as the rebuild will start by creating a 3TB partition on the 4TB disk.  Normally the 3TB is then expanded to fill the 4TB disk after the rebuild finishes.  I am not sure that the file system can be expanded to use the additional space if it has corruption.

As far as I know it's never been tried, and you've got nothing to lose.