I am moving a number of drives from RFS to XFS .  It has been slow but reliable following the wiki guide.

 

However last night one drive coughed and puked when it was.

 

 rsync -avPX /mnt/disks/SeagateLAFX/ /mnt/disk10/

*** Skipping any contents from this failed directory ***
rsync: recv_generator: mkdir "/mnt/disk10/unRaid" failed: Structure needs cleaning (117)

root@Kim:/mnt/disk10# ls
ls: reading directory .: Structure needs cleaning

 

 

Target drive received about .5tb of 3tb of data.  This is the first time I used unassigned devices plugin to mount the source drive.  Might that be an issue?

I am moving a number of drives from RFS to XFS .  It has been slow but reliable following the wiki guide.

 

However last night one drive coughed and puked when it was.

 

 rsync -avPX /mnt/disks/SeagateLAFX/ /mnt/disk10/

*** Skipping any contents from this failed directory ***
rsync: recv_generator: mkdir "/mnt/disk10/unRaid" failed: Structure needs cleaning (117)

root@Kim:/mnt/disk10# ls
ls: reading directory .: Structure needs cleaning

 

 

Target drive received about .5tb of 3tb of data.  This is the first time I used unassigned devices plugin to mount the source drive.  Might that be an issue?

I think it's very unlikely the plugin is the issue. More likely filesystem corruption.

Freshly pre-cleared drive?

 

What tools should I try on this xfs drive?

The wiki article for Check Disk Filesystems has been updated to cover XFS and you can do it from the webGUI.

The wiki article for Check Disk Filesystems has been updated to cover XFS and you can do it from the webGUI.

 

I ended up using command line mode for this, and after 4 hours it was still printing dots across the bottom of my screen.

 

It briefly complained about finding a second superblock, and went chugging along.

 

xfs_repair -v /dev/md10

 

I stopped and detached it from my Areca controller and started it again on a motherboard port hoping for better luck.

 

unRaid claimed the disk was unformatted so I allowed it to reformat and now I have a fresh clean empty drive.

 

How did rsync transfer 500gb to an unformatted drive?  Is my drive precleared properly or not?

 

I started the rsync again, and we'll see how it goes.

How did rsync transfer 500gb to an unformatted drive?  Is my drive precleared properly or not?

When rsync transferred data to the drive it was formatted but the file system apparently got so corrupted that it essentially became unformatted.  Either that or you switched the file type on the drive from one to the other when you transferred the drive to the MB port.  My best guess.

I wonder if I needed to do a second preclear to verify that the disk was all zeroed out??

I wonder if I needed to do a second preclear to verify that the disk was all zeroed out??

That is what the post-read does. If you still have a copy of the preclear report it will tell you if it detected any non-zero data.

I have no doubt that it was cleared prior to first formatting.  But rsync copied 500gb to the drive before failing.

 

I stopped the array, went to maintenance mode and ran xfs_repair, which ran for hours looking for second superblock.  I stopped that process, stopped the array, and moved from an Areca port to a motherboard port.  At that point unRaid claimed the drive was unformatted and I allowed it to reformat and go.  Last night rsync copied 2.7tb with no issue.

 

By doing the second format and rsync, do you think I invalidated the preclear?

I have no doubt that it was cleared prior to first formatting.  But rsync copied 500gb to the drive before failing.

 

I stopped the array, went to maintenance mode and ran xfs_repair, which ran for hours looking for second superblock.  I stopped that process, stopped the array, and moved from an Areca port to a motherboard port.  At that point unRaid claimed the drive was unformatted and I allowed it to reformat and go.  Last night rsync copied 2.7tb with no issue.

 

By doing the second format and rsync, do you think I invalidated the preclear?

The only reason for a drive to be clear is so it will be consistent with parity when it is added to a new slot. You might just do a parity check to make sure.

And if parity hasn't been created yet?

And if parity hasn't been created yet?

Then it doesn't matter what's on the disk if the filesystem is working. Once you build parity you will be able to reconstruct that disk (or any other) just like it is.

 

Do you know how parity works?

Yes that's what I thought. But it was a strange one.

 

In other words, if parity hasn't been generated, there is no need to pre-clear new disks.

Yes that's what I thought. But it was a strange one.

 

In other words, if parity hasn't been generated, there is no need to pre-clear new disks.

I would preclear new disks to make sure they don't die right after I add them to the array.  But otherwise NO there is no reason to preclear them except to give them a good workout if you don't have a parity drive.

Most of the configuration changes I make are rebuilding parity onto a larger drive, or rebuilding a data disk onto a larger drive. Neither of these scenarios require a clear disk. I always preclear new disk anyway just for testing purposes, and I always recommend others do as well.