Author Topic: Potential Samsung F4 issues.  (Read 52477 times)

Offline mcs

  • Full Member
  • ***
  • Posts: 172
Potential Samsung F4 issues.
« on: December 04, 2010, 06:11:19 AM »
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
« Last Edit: January 03, 2011, 11:20:21 AM by Rajahal »

Offline Joe L.

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 18824
Re: Potential Samsung F4 issues.
« Reply #1 on: December 04, 2010, 06:34:31 AM »
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.

Offline Chris Pollard

  • Hero Member
  • *****
  • Posts: 777
    • Frumble Fabrics
Re: Potential Samsung F4 issues.
« Reply #2 on: December 04, 2010, 06:48:55 AM »
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?
unRAID : Lian Li 343-B, Asus M3A32-MVP Deluxe, Athlon 64 x2 4000+, 6gb RAM, Intel 330 120gb SSD Cache, Supermicro AOC-SASLP-MV8 x2 - Retired
unRAID2 5.0.2 : X-Case RM424, Supermicro X9SCM-F, Xeon E3-1230 v2, AOC-SASLP-MV8 x2, Seagate ST1000DX001 1TB SSHD Cache,  8gb ECC - 40.03TB
unRAID3 6.0b10a : X-Case RM424, Supermicro X10SLM-F-B, Xeon E3-1220 v3, AOC-SASLP-MV8, 500gb Momentus XT Cache, 8gb ECC - 25.47TB
unRAID Test Box : HP Microserver N36L, 2gb RAM - 2.55TB Usable

Offline Joe L.

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 18824
Re: Potential Samsung F4 issues.
« Reply #3 on: December 04, 2010, 07:17:09 AM »
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.

Offline Chris Pollard

  • Hero Member
  • *****
  • Posts: 777
    • Frumble Fabrics
Re: Potential Samsung F4 issues.
« Reply #4 on: December 04, 2010, 07:24:41 AM »
So rsync doesn't check it has written the data correctly before deleting the original files?  or do I not understand the actual problem? :)
unRAID : Lian Li 343-B, Asus M3A32-MVP Deluxe, Athlon 64 x2 4000+, 6gb RAM, Intel 330 120gb SSD Cache, Supermicro AOC-SASLP-MV8 x2 - Retired
unRAID2 5.0.2 : X-Case RM424, Supermicro X9SCM-F, Xeon E3-1230 v2, AOC-SASLP-MV8 x2, Seagate ST1000DX001 1TB SSHD Cache,  8gb ECC - 40.03TB
unRAID3 6.0b10a : X-Case RM424, Supermicro X10SLM-F-B, Xeon E3-1220 v3, AOC-SASLP-MV8, 500gb Momentus XT Cache, 8gb ECC - 25.47TB
unRAID Test Box : HP Microserver N36L, 2gb RAM - 2.55TB Usable

Offline Joe L.

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 18824
Re: Potential Samsung F4 issues.
« Reply #5 on: December 04, 2010, 07:38:35 AM »
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.
« Last Edit: December 04, 2010, 07:49:23 AM by Joe L. »

Offline Chris Pollard

  • Hero Member
  • *****
  • Posts: 777
    • Frumble Fabrics
Re: Potential Samsung F4 issues.
« Reply #6 on: December 04, 2010, 07:53:40 AM »
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 :)
unRAID : Lian Li 343-B, Asus M3A32-MVP Deluxe, Athlon 64 x2 4000+, 6gb RAM, Intel 330 120gb SSD Cache, Supermicro AOC-SASLP-MV8 x2 - Retired
unRAID2 5.0.2 : X-Case RM424, Supermicro X9SCM-F, Xeon E3-1230 v2, AOC-SASLP-MV8 x2, Seagate ST1000DX001 1TB SSHD Cache,  8gb ECC - 40.03TB
unRAID3 6.0b10a : X-Case RM424, Supermicro X10SLM-F-B, Xeon E3-1220 v3, AOC-SASLP-MV8, 500gb Momentus XT Cache, 8gb ECC - 25.47TB
unRAID Test Box : HP Microserver N36L, 2gb RAM - 2.55TB Usable

Offline Joe L.

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 18824
Re: Potential Samsung F4 issues.
« Reply #7 on: December 04, 2010, 08:05:58 AM »
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.

Offline Chris Pollard

  • Hero Member
  • *****
  • Posts: 777
    • Frumble Fabrics
Re: Potential Samsung F4 issues.
« Reply #8 on: December 04, 2010, 08:09:50 AM »
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 :)
unRAID : Lian Li 343-B, Asus M3A32-MVP Deluxe, Athlon 64 x2 4000+, 6gb RAM, Intel 330 120gb SSD Cache, Supermicro AOC-SASLP-MV8 x2 - Retired
unRAID2 5.0.2 : X-Case RM424, Supermicro X9SCM-F, Xeon E3-1230 v2, AOC-SASLP-MV8 x2, Seagate ST1000DX001 1TB SSHD Cache,  8gb ECC - 40.03TB
unRAID3 6.0b10a : X-Case RM424, Supermicro X10SLM-F-B, Xeon E3-1220 v3, AOC-SASLP-MV8, 500gb Momentus XT Cache, 8gb ECC - 25.47TB
unRAID Test Box : HP Microserver N36L, 2gb RAM - 2.55TB Usable

Offline pras1011

  • Sr. Member
  • ****
  • Posts: 448
Re: Potential Samsung F4 issues.
« Reply #9 on: December 04, 2010, 08:50:49 AM »
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?
X Case RM420 (Norco 4220)
Asus Gene V Mobo
Intel G645 CPU
1 x Hitachi 7K4000 4TB parity hdd
14 x Hitachi 7K3000 Ultrastar 3TB hdd
2 x Supermicro AOC-SAS2LP-MV8 (4.0.0.1808 firmware)
Corsair TX650W PSU
G Skill Ripjaws X 8GB
Unraid 5.0.5

Offline johnny121b

  • Full Member
  • ***
  • Posts: 201
Re: Potential Samsung F4 issues.
« Reply #10 on: December 04, 2010, 09:05:26 AM »
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???

« Last Edit: December 04, 2010, 09:26:32 AM by johnny121b »

Offline graywolf

  • Hero Member
  • *****
  • Posts: 599
Re: Potential Samsung F4 issues.
« Reply #11 on: December 04, 2010, 09:11:01 AM »
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.
ESXi 5.0, Norco RPC-4224, X9SCM-F-O MB, E3-1240 Xeon CPU, Kingston 16GB ECC DDR3, OZC 120GB SSD & 2TB HDD Data Stores 
*** special thanks to JohnM for his "ATLAS My Virtualized unRAID server"  thread ***

unRAID 5rc16c (VM): Supermicro 3x IBM ServeRAID M1015 (LSI/flashed) Controllers [passthru], 42TB capacity

Other VMs include CentOS (CyberPower UPS automatic VM/Esxi shutdown), Win7, WinXP, Ubuntu

Offline Chris Pollard

  • Hero Member
  • *****
  • Posts: 777
    • Frumble Fabrics
Re: Potential Samsung F4 issues.
« Reply #12 on: December 04, 2010, 09:12:44 AM »
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.
unRAID : Lian Li 343-B, Asus M3A32-MVP Deluxe, Athlon 64 x2 4000+, 6gb RAM, Intel 330 120gb SSD Cache, Supermicro AOC-SASLP-MV8 x2 - Retired
unRAID2 5.0.2 : X-Case RM424, Supermicro X9SCM-F, Xeon E3-1230 v2, AOC-SASLP-MV8 x2, Seagate ST1000DX001 1TB SSHD Cache,  8gb ECC - 40.03TB
unRAID3 6.0b10a : X-Case RM424, Supermicro X10SLM-F-B, Xeon E3-1220 v3, AOC-SASLP-MV8, 500gb Momentus XT Cache, 8gb ECC - 25.47TB
unRAID Test Box : HP Microserver N36L, 2gb RAM - 2.55TB Usable

Offline pras1011

  • Sr. Member
  • ****
  • Posts: 448
Re: Potential Samsung F4 issues.
« Reply #13 on: December 04, 2010, 09:21:15 AM »
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!
X Case RM420 (Norco 4220)
Asus Gene V Mobo
Intel G645 CPU
1 x Hitachi 7K4000 4TB parity hdd
14 x Hitachi 7K3000 Ultrastar 3TB hdd
2 x Supermicro AOC-SAS2LP-MV8 (4.0.0.1808 firmware)
Corsair TX650W PSU
G Skill Ripjaws X 8GB
Unraid 5.0.5

Offline Chris Pollard

  • Hero Member
  • *****
  • Posts: 777
    • Frumble Fabrics
Re: Potential Samsung F4 issues.
« Reply #14 on: December 04, 2010, 09:26:38 AM »
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?
unRAID : Lian Li 343-B, Asus M3A32-MVP Deluxe, Athlon 64 x2 4000+, 6gb RAM, Intel 330 120gb SSD Cache, Supermicro AOC-SASLP-MV8 x2 - Retired
unRAID2 5.0.2 : X-Case RM424, Supermicro X9SCM-F, Xeon E3-1230 v2, AOC-SASLP-MV8 x2, Seagate ST1000DX001 1TB SSHD Cache,  8gb ECC - 40.03TB
unRAID3 6.0b10a : X-Case RM424, Supermicro X10SLM-F-B, Xeon E3-1220 v3, AOC-SASLP-MV8, 500gb Momentus XT Cache, 8gb ECC - 25.47TB
unRAID Test Box : HP Microserver N36L, 2gb RAM - 2.55TB Usable