Reconstructed drive shows less data (1.5T missin), no errors

While setting up a new unraid machine and moving my drives to this machine, one of the SATA cables was lose. Unraid dropped the disk and marked it disabled. I had a replacement available and plugged in the replacement to reconstruct the data in the missed drive. Before the data reconstruction, there were no reported parity errors and during the data reconstruction there were no reported errors either. I assumed all was fine until this morning when I happened to see the main dashboard that the reconstructed drive has only 36GB. I took a printout of the dashboard before moving the drives to the new machine, it shows about 2T data on the original drive. My next task is to plug in the original drive when I get a chance and compare what's missing.

I'd like to know what failed so that I can be confident of being able to reconstruct the data and trust my parity protection. As of now, there were no warning signals that would have alerted me of the lost data.

See check disk file systems in my sig.

For the new data drive, I formatted it as xfs with the intention to move to this file system when possible. Did you suggest to check the file system on the old drive or the replacement one? Is there a similar tool for the xfs file system?

Thanks!

See check disk file systems in my sig.

It was my understanding that parity rebuilds have to occur between like file systems.  So if the old drive had RFS, then the new drive would need to be formatted as RFS in order for a parity rebuild to work.

I'm not sure if it is too late.  Someone else more knowledgeable will need to comment.

Formatting is not part of the rebuild process. How exactly did you get to this point?

1. Stopped the array,

2. replaced the missing disk,

3. clicked on the icon left of the disk which showed format options, selected xfs, formatted and

4. the file share came back online.

The disk rebuild process automatically and in Main > Array Operation it said disk rebuild in progress. Did I miss any step?

That being said, I remember the discussion about unraid v6 supporting mixed file format and that xfs filesystem is the way to go in future. So Unraid does support mixed file systems.

Formatting is not part of the rebuild process. How exactly did you get to this point?

 

1. Stopped the array,

2. replaced the missing disk,

3. clicked on the icon left of the disk which showed format options, selected xfs, formatted and

4. the file share came back online.

 

The disk rebuild process automatically and in Main > Array Operation it said disk rebuild in progress. Did I miss any step?

 

That being said, I remember the discussion about unraid v6 supporting mixed file format and that xfs filesystem is the way to go in future. So Unraid does support mixed file systems.

 

 

 

Formatting is not part of the rebuild process. How exactly did you get to this point?

the proper way would have been to

[*]stop the array

[*]replace the missing disk

[*]rebuild disk

and once your disk was working correctly, start the process to move to xfs by either getting a new disk to start or moving files off a disk and reformatting the empty disk to xfs.  I've moved all my drives to xfs except my cache which is btrfs.

You essentially tried to do what I asked about here:  http://lime-technology.com/forum/index.php?topic=36183.msg336802#msg336802

John

Ah KRAP!

I am now copying files off the old drive to the new one, hope it goes okay. Maybe an alert should be included when a user tries to change the replacement disk filesystem on the final version of unraid.

You essentially tried to do what I asked about here:  http://lime-technology.com/forum/index.php?topic=36183.msg336802#msg336802

 

John

Ah KRAP!

 

I am now copying files off the old drive to the new one, hope it goes okay. Maybe an alert should be included when a user tries to change the replacement disk filesystem on the final version of unraid.

I am in the process now of migrating all of my data disks from RFS to XFS.  I essentially mounted a spare drive using SNAP, copied all contents from DISK1 to it, formatted DISK1 as XFS and copied everything back to it.  The important part is to leave the parity drive enabled so the new bits are written to it.  Unfortunately, this makes the copy-back process SLOOOOOOOOOW!  I'm probably averaging ~20MB/s so you can imagine how long 1.8TB will take.  Right now i'm looking at ~25 hours. 

Of course, you can take parity out of the mix and speed things up but bad things could happen.

2 down...8 to go.

Ah KRAP!

 

I am now copying files off the old drive to the new one, hope it goes okay. Maybe an alert should be included when a user tries to change the replacement disk filesystem on the final version of unraid.

 

 

I am in the process now of migrating all of my data disks from RFS to XFS.  I essentially mounted a spare drive using SNAP, copied all contents from DISK1 to it, formatted DISK1 as XFS and copied everything back to it.  The important part is to leave the parity drive enabled so the new bits are written to it.  Unfortunately, this makes the copy-back process SLOOOOOOOOOW!  I'm probably averaging ~20MB/s so you can imagine how long 1.8TB will take.  Right now i'm looking at ~25 hours. 

 

Of course, you can take parity out of the mix and speed things up but bad things could happen.

 

2 down...8 to go.

rsync

rsync

You left parity enabled?  Do you remember what your writes speeds were?

I'd like to blame the fact that I an reading from and writing to WD green drives 20MB/s seems slow to me.  My parity drive is a Hitachi 7200 RPM.

EDIT:

Hell, now that I look I'm not even getting 20MB/s:

Movies/The Bridge on the River Kwai (1957)/
Movies/The Bridge on the River Kwai (1957)/The Bridge on the River Kwai (1957).mkv
32,519,843,189 100%   20.45MB/s    0:25:16 (xfr#1148, to-chk=678/2100)
Movies/The Croods (2013)/
Movies/The Croods (2013)/The Croods (2013).mkv
21,286,252,532 100%   19.16MB/s    0:17:39 (xfr#1149, to-chk=677/2100)
Movies/The Departed (2006)/
Movies/The Departed (2006)/The Departed (2006).mkv
22,127,628,284 100%   14.46MB/s    0:24:18 (xfr#1150, to-chk=676/2100)
Movies/The Evil Dead (1981)/
Movies/The Evil Dead (1981)/The Evil Dead (1981).mkv
17,952,888,479 100%   16.43MB/s    0:17:21 (xfr#1151, to-chk=675/2100)
Movies/The Hobbit - The Desolation of Smaug (2013)/
Movies/The Little Drummer Boy (1968)/
Movies/The Lord of the Rings - The Return of the King (2003)/
Movies/The Lord of the Rings - The Return of the King (2003)/The Lord of the Rings - The Return of the King (2003).mkv
81,323,129,520 100%   13.76MB/s    1:33:56 (xfr#1152, to-chk=674/2100)
Movies/The Passion of the Christ (2004)/
Movies/The Passion of the Christ (2004)/The Passion of the Christ (2004).mkv
25,001,766,292 100%   16.85MB/s    0:23:35 (xfr#1153, to-chk=673/2100)

You left parity enabled?  Do you remember what your writes speeds were?

 

I'd like to blame the fact that I an reading from and writing to WD green drives 20MB/s seems slow to me.  My parity drive is a Hitachi 7200 RPM.

Why does it always seem that it is my system that suck at transfer speeds?!?!

Could it have been the rsync command?

What did you use?

Pretty vanilla...

rsync -arv --stats --progress /mnt/disk/transfer/disk1/ /mnt/disk1/

Doing a little more reading and found this:  http://lime-technology.com/forum/index.php?topic=22095.0

Another user with 2x AOC-SASLP-MV8 and was experiencing the same slow write speeds as me.

I used

rsync -av --progress --remove-source-files /mnt/diskX/ /mnt/diskY/

Doing a little more reading and found this:  http://lime-technology.com/forum/index.php?topic=22095.0

 

Another user with 2x AOC-SASLP-MV8 and was experiencing the same slow write speeds as me.

Only 160GB more to go.  As soon as this is finished I want to poke around in the BIOS for both the MB and the AOC cards to make sure everything looks OK.

My large file transfers sustain at 55 MB/s and bursts start at 170 MB/s. These are between two ST3000DM001 (one in raid and another outside raid) with the parity enabled.  Are these transfer speeds considered good?