Hello,

 

After suffering a drive failure (most likely due to a cable problem) and a parity rebuild back onto the "failed" drive which didn't have any data on it anyway, I'm noticing that some files now have different characteristics than before.  How did I find this do you say? 

 

I'm in the middle of organizing and cleaning up my media.  I had some mp3's on my local machine that had been copied back to the unRaid server.  Using teracopy to copy back, skipping the copy but letting it verify, the files I've tried so far are showing Size mismatches.

 

I looked at both the local copy and the remote copy.

 

Local Copy: 5157 KB

Remote Copy: 5120 KB

 

This is happening on a few files, mainly mp3's so far, but I'm starting to check others.

 

I'm assuming this is not a good thing?  How do I know which file is the correct file?  Any advice on this would be appreciated.  The drive that failed contained no data, all my data is on one drive.  I've looked through my syslog after the rebuild of parity and reboot, and it's not showing anything unusual that I could see.  If it's of value I'll post it.

 

Thanks

 

So, I copied the file from my PC to an ubuntu sandbox, and ran sum against it.

 

Ubuntu: 56018

Tower: 61051

 

The files are certainly different...  Now to determine which is the "good" copy, if one is bad.

Following the instructions here http://lime-technology.com/forum/index.php?topic=463.0, I have run reiserfsck against all my data drives.  The one that had failed didn't have any data, and reiserfsck cleared it.

 

Here's the output of reiserfsck against the drive with the data, with the file system umounted.

 

---snip---

root@Tower:~# reiserfsck /dev/md1

reiserfsck 3.6.21 (2009 www.namesys.com)

 

*************************************************************

** If you are using the latest reiserfsprogs and  it fails **

** please  email bug reports to [email protected], **

** providing  as  much  information  as  possible --  your **

** hardware,  kernel,  patches,  settings,  all reiserfsck **

** messages  (including version),  the reiserfsck logfile, **

** check  the  syslog file  for  any  related information. **

** If you would like advice on using this program, support **

** is available  for $25 at  www.namesys.com/support.html. **

*************************************************************

 

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

Will put log info to 'stdout'

 

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes

###########

reiserfsck --check started at Tue Oct 19 20:44:22 2010

###########

Replaying journal: Done.

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

Checking internal tree.. finished

Comparing bitmaps..finished

Checking Semantic tree:

finished

No corruptions found

There are on the filesystem:

       Leaves 149252

       Internal nodes 908

       Directories 1762

       Other files 25715

       Data block pointers 148786462 (90915 of them are zero)

       Safe links 0

###########

reiserfsck finished at Tue Oct 19 21:20:07 2010

###########

---/snip---

 

I'm a little concerned that something on the unraid server has changed the files.  I found a copy on my whs server, and the file size is the same as my PC copy (didn't check the sum yet).  

 

Has anyone seen anything like this in the past?  I love the concept of unRaid, but if it's going to be chewing up my files with no recourse and zero notification, I don't like that.  If I'd not checked this out, there's zero indication from unRaid that something has gone wrong with these files.

 

 

The drive rebuild did not cause that existing data on a drive that was not rebuilt to be damaged. It was likely damaged when you copied it over or unRAID is just not reading it back correctly.

 

A first easy test is to boot the server and pick the memtest from the screen that first pops up. Let it run over night and make sure there are no errors.

 

A second test is to run a parity check. You should never get errors. So, if you get errors each time you run it then you know that the drives are not being read correctly. Then, it's a question of them only being read incorrectly or of both not being written or read correctly. As in, the data on the drive could be OK but you're not getting it read back correctly or the data is completely hosed and you'll have to replace it all.

 

After that, you will have to test/swap hardware parts and do a copy/compare or copy/checksum on some files from your PC to the server until you figure out what is causing the corruption.

 

FYI, I had a 2-port SATA to PCIe x1 card that was corrupting any files copied to disks that were attached to it. I ended up just getting rid of the card. I don't recall testing if the data was written correctly and not read correctly but it worked in my PC but was broken in my unRAID box.

 

Peter

 

 

Thanks for the reply.

 

I didn't think (and hope I didn't imply) that the parity rebuild caused this.  It doesn't make sense that it could because that's a read only operation to the drive that had data.  Could teracopy have given bogus info when it gave CRC's on the data copy to unraid?

 

It's too bad I didn't read this before I left for work .  I'll try the memtest when I get home today and let it run overnight into tomorrow.  That outta give it 24 hours or so.  The data drives in question are directly connected to the mobo in this case.  I've never gotten errors during a parity check.  Even after the drive failure, when parity kicked in again, the parity itself ran clean.

 

This is an atom board, there's not much to replace .

 

My Parity and current Data drive is on the mobo.  The other drives are on a promise controller, but have no data on them.  And my cache drive is an IDE drive on the mobo also.

 

Just an odd situation is all...

I agree that you should test the memory first.

 

I've never heard of TeraCopy itself corrupting files during a transfer, but I suppose it is possible.  Maybe try doing some more test transfers to see if you can catch the corruption in the act. 

 

Do you have an alternate network cable you could try?  That's another easy thing to test.

 

Finally, is it possible that there's some completely normal reason for the file sizes to change?  For example, maybe your media player has updated the .mp3's with new album art, metatags, etc.?  Have you tried actually playing back both copies to see if both work/sound good?

The memory test is running now.  Will it stop on its own?  Or run until I stop it?

 

Yea, I've never had a problem with teracopy.  And I always verify on copy, it has always copied clean.

 

I'll try another network cable after the memtest is complete.

 

No, I didn't try listening to see if there's a difference.  Didn't think that the media player might've updated it. 

 

Thanks,

The memory test is running now.  Will it stop on its own?  Or run until I stop it?

It will run until you stop it.

Hello,

 

So the memtest ran for about 16 hours, no errors.  I forced another parity check after it restarted.  No errors there.

 

Thanks to Raj, I started poking around more.  The only files that have changed are mp3 files.  No sure what would have done it, I don't have any media managers on my main PC or WHS server.  I run iTunes on my laptop, but it doesn't touch either sets of that data.

 

I don't really care about mp3's, I can just put the cds back in the drive and pull them again.  I was more concerned about a change in the sum output, for when I store something a little more important that can't be saved.  It would have been the same scenario.  The data would have been copied also on my WHS server, so I'd have a backup.

 

It was more a concern on what changed it

Good to hear it's just the mp3's and that probably is one of the media programs you're using to play them.

 

Teracopy always verifying a good copy is a very good sign that your data is making it to the hard drives correctly. And once there, there is no reason to believe unRAID would just corrupt it.

 

Peter