New HDD showing wrong size during Data Rebuild?

[johngalt]

Not sure what's going on here, but I was upgrading a 6TB drive to a 18TB drive and now the drive size is wrong. Unraid is showing Size as 408GB, Used as 18.4EB, and Free as 12.2TB. It also throws off the calcs for the total Array size. It shows 106TB where it should be 134TB, Used as 18.4EB, and Free as 25.6TB.

 

Data Rebuild seems to be running properly. It shows the Total Size as 18TB and is closing in on 1TB complete. Should I just let this finish and restart and see if the problem corrects itself?

Edited January 25, 2022 by johngalt

[JorgeB]

Please post the diagnostics.

[johngalt]

tower-diagnostics-20220126-0655.zip

[JorgeB]

Once the rebuild finishes check filesystem on that disk.

 

P.S. reiser is not recommended for a long time, you should convert all disks to xfs.

[johngalt]

Thanks, will do.

 

I'm in the process of converting now, it's the reason I picked up the 18TB drives. 

[johngalt]

Rebuild finished. I restarted the server to see what it would do before running check filesystem and it's hung on Mounting that disk. Been going for twenty minutes now. Won't respond to reboot or shutdown commands....just stuck on Mounting the new disk drive.

[JorgeB]

Reiserfs can take a long time to mount, hours even for large filesystems, when there are issues or it's replaying the journal.

[JonathanM]

1 hour ago, johngalt said:

Been going for twenty minutes now.

In the past I've had ReiserFS filesystems that take close to 18 hours to replay and mount after an unclean dismount.

 

One of the many reasons to migrate to a modern filesystem.

[johngalt]

ok, finally up and running. Ran filesystem check and got the following:

 

Quote

reiserfsck 3.6.27

 

Will read-only check consistency of the filesystem on /dev/md9

Will put log info to 'stdout'

###########

reiserfsck --check started at Thu Jan 27 15:00:25 2022

###########

Replaying journal: Replaying journal: Done.

Reiserfs journal '/dev/md9' in blocks [18..8211]: 0 transactions replayed

reiserfs_open_ondisk_bitmap: wrong either bitmaps number,

count of blocks or blocksize, run with --rebuild-sb to fix it

reiserfsck: Could not open bitmap

 

I've read the instructions for what to do next, but not really sure what happened with this drive. Preclear didn't have any errors and it wasn't until I put this drive into the array that there were errors.

 

Is the best course of action to continue with the rebuild-sb command? What will happen to the data on the disk during this process? Would putting the original drive back in and exchanging the 18TB drive for a new one be an easier solution?

[JorgeB]

I forgot that reiser is limited to 16TiB max size, so you'll need to go back to the old disk, convert to xfs, then you can upgrade again.

[johngalt]

That was going to be my next question since my plan was just to convert anyway.

 

So replace the new drive with the original one, I assume this will now need to rebuild the drive again? Would it be safer to replace with a different 6tb drive so I can keep the original data intact in case of a worst case scenario?

 

Then use unbalance to move the data off the 6tb disk, put the 18tb drive back in, format as XFS, and continue from there?

[johngalt]

Hmmm, can't start the array with the 6TB drive now that there's been an 18TB in its place. "The replacement disk must be as big or bigger than the original".

 

I can think of two options at this point, but I'm obviously an amateur when it comes to this:

 

1) Use unbalance to move the data off the 18tb drive and onto another drive in the array and then format the 18tb drive as XFS.

 

2) Format the 18tb drive as XFS and then move the data onto the drive from the 6tb drive that's been pulled.

 

Would one of these be a better solution than the other, or is there a better method I'm not thinking of?

Edited January 27, 2022 by johngalt

[JorgeB]

9 hours ago, johngalt said:

2) Format the 18tb drive as XFS and then move the data onto the drive from the 6tb drive that's been pulled.

This is what I would do.