Potential Samsung F4 issues.

[mcs]

Just read a report that indicates Samsung F4's can generate Bad Blocks when hdparm is called on them. More details on:
http://sourceforge.net/apps/trac/smartmontools/wiki/SamsungF4EGBadBlocks

[Joe L.]

Just read a report that indicates Samsung F4's can generate Bad Blocks when hdparm is called on them. More details on:
http://sourceforge.net/apps/trac/smartmontools/wiki/SamsungF4EGBadBlocks

Now that is a reason to stay waaaaaayyyyyy clear from those drives until they can release a firmware fix.

[Chris Pollard]

sounds nice.  Always love to hear about silent corruption.  

to turn off write caching -

hdparm -W 0 /dev/sda  (replace sda with your disk)

to look at write caching status :-

hdparm -W /dev/sda (replace sda with your disk)

Question for the experts : Will the mover script pickup this corruption?

[Joe L.]

Question for the experts : Will the mover script pickup this corruption?

No script will pick up on the problem...  There is no error returned but the data "written" to the disk is not written to the disk platter.

It is even worse than that... If you do a parity "check" it will read the zeros (or whatever) was in the sectors that should have been written, report a parity error and then update parity to reflect the bad data on the disk.  Ouch.

If you disabled the F4 disk (un-assign it) then start the array without it, then stop and re-assign it you can get the parity disk in combination with the other disks to potentially write the correct data to the F4 drive as part of its re-construction.   You'll be without parity protection until it completes, but at least your data will be good when it is done.

This will only work if you have not over-written parity with the stock unRAID "Check" button before attempting the drive re-construction.

Joe L.

[Chris Pollard]

So rsync doesn't check it has written the data correctly before deleting the original files?  or do I not understand the actual problem?

[Joe L.]

So rsync doesn't check it has written the data correctly before deleting the original files?  or do I not understand the actual problem?

I did not think of that... I'm not sure if it reads it back when on the same server, or just does the checksum when used across servers.

HOWEVER... since the file was just written it would still be in the Linix buffer cache and if read back it would not even go to the disk itself unless the file was huge and could not all be buffered.  The file would be read back from memory not the physical disk.

[Chris Pollard]

Yeah,  I'd pretty much came to that conclusion too Joe.  Seems I have 800gb of data with a question mark hanging over it......  time to get the original media out methinks

[Joe L.]

Yeah,  I'd pretty much came to that conclusion too Joe.  Seems I have 800gb of data with a question mark hanging over it......  time to get the original media out methinks

If you trust the rest of your disks,
Stop the array
un-assign the F4 disk
Start the array  (this will cause unRAID to forget the serial number of the F4 disk so it can be used as its own replacement)
Stop the array
re-assign the F4 disk
Start the array.
Let it re-construct the F4 disk.  It will fix any of the "data blocks" that were never written to the disk.

Yes you'll be without parity protection until the disk is re-constructed, but since you are really writing back exactly what was on the disk you can recover (somewhat) if another disk were to fail by forcing parity to be trusted.   You are really only going to "potentially" update the blocks that were not correctly written originally.

Joe L.

[Chris Pollard]

Actually, thinking about it, under what conditions would this problem occur under normal unRaid operation?  Refreshing main.htm while writing to the dodgy disk? Using smartctl or hdparm from the command line while writing obviously.

At this point I'm thinking I'll just disable write cache for the drive and suck up any corruption if and when I find it.  Parity check ran on the 1st without listing any errors and I've watched maybe 50% of the films on that drive without noticing anything.

Thanks for the instructions Joe but my monthly Parity check ran 3 days ago so I think, if I understand correctly, any bad data is now part of the array

[pras1011]

I am building a new server and I have 7 brand new untouched F4. I have one Hitachi 7k2000 that will act as parity.

How do I put them into the server to avoid any problems?

[johnny121b]

Oh, this is depressing....especially on December 4th  Thanks for the command line to turn off write caching, Chris.

By turning off the caching as described, will it remain off if the server is restarted?  If not, how can I ensure that it does?

I know that I have never issued the commands at the command-line prompt....but are they something that UnMenu or even UnRaid make-use-of???

[graywolf]

Have no clue if it would turn back on with a server restart/reboot

But if you wanted, you could put the command in your go script.

[Chris Pollard]

I am building a new server and I have 7 brand new untouched F4. I have one Hitachi 7k2000 that will act as parity.

How do I put them into the server to avoid any problems?

turn off write caching before you write any data to them :-

hdparm -W 0 /dev/sda  (replace sda with your disk)

wait for a new firmware from Samsung.

By turning off the caching as described, will it remain off if the server is restarted?  If not, how can I ensure that it does?

The setting survives a reboot on my system, yes.

[pras1011]

This is absolutely ridiculous!! There doesn't seem to be any HDD that is safe to use. Apart from maybe the Hitachi 7K2000 2TB but that hdd is noisy, runs extremely hot and expensive!

[Chris Pollard]

This is absolutely ridiculous!! There doesn't seem to be any HDD that is safe to use. Apart from maybe the Hitachi 7K2000 2TB but that hdd is noisy, runs extremely hot and expensive!

What about the Seagate ST32000542AS ?  or is there some problem with that one too?