Damaged disk

Comments

• Shane

  May 2012 Resident Guru

  Hmm. Seems like you have an opportunity to do some tests as to if/how drivepool reacts to mis-matching duplicates.

  
  

  More seriously, the safe action would be to copy the known good physical copy to a different non-pooled disk before doing anything else.

  
  

  As to replacing the disk, the answer is "it depends". I've had seemingly good disks fail and I've had disks with multiple bad sectors keep going - but also vice versa. Personally, I'd treat the disk with suspicion and not rely on it for anything I didn't have backed up or at least duplicated.

  Share on Twitter
• Paaland

  May 2012 Member

  I did'nt seem like DP even detected that one of the copies was corrupt. I assume making a MD5 sum of each of the file parts are too costly. I did a compare on each of the two parts and they were different. I deleted the corrupt one and then DP detected that my pool needed re-balancing. Ran the balance process and hey presto the file was re-duplicated.

  
  

  A bad cluster on a HDD is something that probably both the HDD and the OS tries to hide and not something DP would detect unless it was actively comparing file-parts on access (which would kill performance). 

  
  

  But I'd really like to see a better integration between Scanner and DrivePool. So when scanner detects a problem on a HDD and finds a corrupt file it should automatically remove the corrupt copy and make a fresh one. Then alert the user to what's it's done. 

  
  

  Both tools are great by them selves, but make them work together and the sum is even better.

  Share on Twitter
• Shane

  May 2012 Resident Guru

  Hmm. I don't know if DrivePool makes use of NTFS alternate streams (AS) at the file level, but I'd be curious to see what kind of performance hit you'd get from calculating the MD5 or SHA1 hash when writing the file in the first place and adding it to the file's AS, and when reading the file re-checking the hash and seeing if it still matches the one stored in the AS. Certainly any modern dual core CPU should be able to do MD5 without breaking a sweat (especially if it's only being used in a file server role); I suspect the performance hit would be the additional disk stream IO (and given a hash is a few bytes, most of that would probably be access time rather than transfer time)?

  
  

  Of course, I could be wildly wrong.

  Share on Twitter
• Paaland

  May 2012 Member

  Your idea seems good when reading or writing a whole file. But remember that you can read/write to any part of a file, and a file can be very large.

  
  

  If I write 2MB of data to a 2GB file you'd have to scan through the whole file in order to calculate the MD5. The same is true for reading just part of the file. In order to detect an error you'd have to scan the whole file and calculate the MD5 sum. This would seriously hurt performance.

  
  

  The best bet imho is to let Scanner tell drive pool that it's detected a potential problem and have to perform actions accordingly.

  Share on Twitter