Samsung HD204UI (2TB) disks causing headache. (Write speed > read speed)

[almagest]

Hello.

I've just built my first NAS server, but have issues with the Samsung drives used.
Im aware that they use the new 4K sectors instead of the common 512b ones.

Installed the FreeNAS-8.0.1-BETA3-amd64 version of FreeNAS, which allows to tick the 4K checkbox when creating a RAIDZ volume.

I did the dd-read/write tests;

Code:

freenas# dd if=/dev/zero of=/mnt/nas/ddfile bs=1m count=10000
10000+0 records in
10000+0 records out
10485760000 bytes transferred in 57.899730 secs (181102053 bytes/sec)
freenas# dd if=/mnt/nas/ddfile of=/dev/zero bs=1m count=10000
10000+0 records in
10000+0 records out
10485760000 bytes transferred in 101.018096 secs (103800808 bytes/sec)

Im a bit dazzled how the write actually is almost twice as fast as reading from the drives. How is that possible?

Other people report 'normal' r/w speeds;
http://hardforum.com/showthread.php?t=1561366

I've read multiple posts here on the freenas board, but still wonder how to proceed.

Samsung drive thread 4K / 512b
http://forums.freenas.org/showthread.php?199-Samsung-HD204UI-2TB-4k-or-512

zdb gives this; (ashift = 12, as opposed to 9, indicating 4K sectors..)

Code:

nas
    version=15
    name='nas'
    state=0
    txg=2596
    pool_guid=7692156913126981140
    hostid=3781610956
    hostname=''
    vdev_tree
        type='root'
        id=0
        guid=7692156913126981140
        children[0]
                type='raidz'
                id=0
                guid=8960000534887433963
                nparity=1
                metaslab_array=23
                metaslab_shift=36
                ashift=12
                asize=7992986566656
                is_log=0
                children[0]
                        type='disk'
                        id=0
                        guid=16499009846811762149
                        path='/dev/gptid/b040bc5d-a8d8-11e0-8354-1c6f65ff36d1'
                        whole_disk=0
                children[1]
                        type='disk'
                        id=1
                        guid=6775391256335755402
                        path='/dev/gptid/b15d47d3-a8d8-11e0-8354-1c6f65ff36d1'
                        whole_disk=0
                children[2]
                        type='disk'
                        id=2
                        guid=11791736992082363252
                        path='/dev/gptid/b247551b-a8d8-11e0-8354-1c6f65ff36d1'
                        whole_disk=0
                children[3]
                        type='disk'
                        id=3
                        guid=10837461982030907558
                        path='/dev/gptid/b337913d-a8d8-11e0-8354-1c6f65ff36d1'
                        whole_disk=0

Ive also done a diskutil to verify the 4K configuration;

Code:

freenas# diskinfo -v /dev/ada0
/dev/ada0
        512             # sectorsize
        2000398934016   # mediasize in bytes (1.8T)
        3907029168      # mediasize in sectors
        0               # stripesize
        0               # stripeoffset
        3876021         # Cylinders according to firmware.
        16              # Heads according to firmware.
        63              # Sectors according to firmware.
        S2H7JD2B422328  # Disk ident.

freenas# diskinfo -v /dev/ada1
/dev/ada1
        512             # sectorsize
        2000398934016   # mediasize in bytes (1.8T)
        3907029168      # mediasize in sectors
        0               # stripesize
        0               # stripeoffset
        3876021         # Cylinders according to firmware.
        16              # Heads according to firmware.
        63              # Sectors according to firmware.
        S2H7JD2B422335  # Disk ident.

freenas# diskinfo -v /dev/ada2
/dev/ada2
        512             # sectorsize
        2000398934016   # mediasize in bytes (1.8T)
        3907029168      # mediasize in sectors
        0               # stripesize
        0               # stripeoffset
        3876021         # Cylinders according to firmware.
        16              # Heads according to firmware.
        63              # Sectors according to firmware.
        S2H7JD2B422332  # Disk ident.

freenas# diskinfo -v /dev/ada3
/dev/ada3
        512             # sectorsize
        2000398934016   # mediasize in bytes (1.8T)
        3907029168      # mediasize in sectors
        0               # stripesize
        0               # stripeoffset
        3876021         # Cylinders according to firmware.
        16              # Heads according to firmware.
        63              # Sectors according to firmware.
        S2H7JD2B422330  # Disk ident.

The RAIDZ volume reports only 5.1 TB available space, the same issue this guy faces;
http://forums.freenas.org/showthread.php?905-RaidZ-and-4x2Tb-yeilds-5.3Tb-available-space-is-this-right

I guess a rough estimate would be that 1/N-drivespace 'dissappears' when creating a RAIDZ/RAID5 volume, but this seems a little to much?

I know that there is an issue with a batch of Samsung HD204UI 2TB drives, Rev A manufactured last year (2010). Luckily my drives are newer than those, and probably not affected by this issue.

My current build is:
4x 2TB Samsung HD204UI
4GB Ram
Gigabyte D525 Motherboard (ATOM 1.8GHZ)

Any hints/tips/ideas would be very welcome.

Thanks for reading a newbie's post.
Andreas.

 

[joeschmuck]

The issue with the Samsung drive would not impact FreeNAS and all 4 of my drives fall into that category.

 

[almagest]

Thanks for the reply!

I will certainly continue to read about ZFS to get a better understaning of it.
Thanks for the heads up regarding the Atom processor, but i am under the impression that a congested CPU is not the reason why Writing outperforms Reading on my NAS.

I watched the CPU closely (using 'top') while issuing the dd commands.
On writing the dd was given as much as 50-60% of the CPU, leaving as little as 20% idle. That seems reasonable since it reports 189MB/sec transferspeed.
On reading with dd (output to /dev/zero) dd was only taking up 16% of the CPU, leaving as much as above 80% idle. And then only 100MB/sec output.
The GUI CPU graphtool supports this usage measurement also.

I still feel the read should perform better than this.

Maybe there are other tests i can perform to investigate further?

 

[Milhouse]

Try setting vfs.zfs.prefetch_disable=0 in /boot/loader.conf, this should improve your read performance.

Read prefetch is disabled by default if you have 4GB (or less) RAM.

 

[almagest]

Thanks alot! That seemed to do the trick!

Code:

freenas# dd if=/dev/zero of=/mnt/nas/ddfile bs=1M count=10000
10000+0 records in
10000+0 records out
10485760000 bytes transferred in 55.577180 secs (188670241 bytes/sec)
freenas# dd if=/mnt/nas/ddfile of=/dev/zero bs=1M count=10000
10000+0 records in
10000+0 records out
10485760000 bytes transferred in 35.501531 secs (295360782 bytes/sec)

Now i have 290MB/Sec read and 188MB/Sec write speeds. Nifty!

For anyone who reads this thread;
If you have issues with r/w speeds on your ZFS nas, try (as the above post said) to enter vfs.zfs.prefetch_disable=0 in /boot/loader.conf (i had to add it to my file)
If you boot off a usbstick as i do, your rootfs will probably be read-only.
To edit the files issue a mount -uw / command (as root) before you try to edit loader.conf

 

[joeschmuck]

Keep an eye on your system stability. I'm not saying this will make your system unstable but if it starts acting up in a few days or next week, don't forget you made this change and revert it back to it's original setting just to see if it is causing the problem. I tend to forget about a change I made if the system works for a short period of time but then it breaks and it's just difficult the link it back to that one change I made weeks ago. I hope it remains stable.

 

[Adam Bradley]

And make sure you patch them http://hardforum.com/showthread.php?t=1566067&page=10 and http://www.samsung.com/global/business/hdd/faqView.do?b2b_bbs_msg_id=386 or lose all your data (like I have) :(

Adam

 

[tropic]

I'm not sure the F4EG patch did anything for my HD204UIs, but updating the firmware to 1AQ10003 turned them into consistent drives on my systems.

@ Adam: Sorry you lost all your stuff. I only lost the last 35GB written to the drive. At least chkdsk enjoyed itself.

 

[almagest]

@Adam: Thanks for the heads up! From what im reading, it seems this firmware bug/issue is only related to disks manufactured before 2011. (and that the newer disks come with the patch installed..)

At least so, according to this site;
http://sourceforge.net/apps/trac/smartmontools/wiki/SamsungF4EGBadBlocks

@tropic: Firmware update, didn't think of that! So the dumb question, how can i verify which firmware im running on my disks? I really want to make sure i have the lastest firmware installed before i fill my disks with data.

Edit: .. and what the crap is up with the Samsung site? Its impossible to locate any firmware at all. All i could find was lousy manuals and some diagnostic program.

 

[tropic]

Here's the fw update I used: http://www.samsung.com/global/business/hdd/faqView.do?b2b_bbs_msg_id=387. Samsung is VERY picky about their support, so if this FW isn't applicable to your market you might be voiding your warranty. OTOH, it made my HD204UIs much less tempermental.

The file will update your firmware version to 1AQ10003.

 

[almagest]

Thanks. Just did an update with the specified file. Protip for any readers; Unetbootin + FreeDos + Patch.

In any case, it did not change the version number on any drives, still 1AQ10001 on all four drives.
Also, i assume bad english only from the samsung guys, but the update said "Copying code..OK" and then "Download OK". I guess they meant installation ok or something similar.

Did not notice any change though in r/w speeds or stability for that matter. Maybe they came prepatched. Better safe than sorry. ;)

Thanks for all help!

 

[joeschmuck]

Make sure you use the firmware for your model number. Tropic's link was for the second set of drives listed (end with /JP1 or /JP2) below and you need to load the correct version for your drives. One size does not fit all. Look at the label on the drive and match the model number.

Model : F4EG HD204UI, HD204UI/Z4, HD204UI/UZ4, HD155UI, HD155UI/Z4, HD155UI/UZ4

Model : F4EG HD204UI/JP1, HD204UI/JP2

An additional note: Samsung was to be incorporating the firmware change in the 2010.12 date production line so you shouldn't have to update if you have that or a later date, however I don't recall where on the Samsung site I read this so your probably safer doing the flash and it gives peace of mind. Too bad Samsung didn't change the firmware number so it could be identified.

EDIT: Just to clarify, Samsung did not change the firmware number for the new firmware. For the HD204UI it starts as [FONT=&quot]1AQ10001[/FONT] and will end with the same number so if you just look at the firmware number, you cannot tell if it's the updated version or not.

@Tropic : Did you use the correct firmware for your drives?

-Mark

 

[almagest]

This is valuable information, i did however notice the differences between my Modelno and the listed ones, and switched from the JP-version to the other one before i started the updates.

And thanks for clarifying the firmware number not being supposed to change.

 

[tropic]

...@Tropic : Did you use the correct firmware for your drives?

No. I originally used the Q&A 37 patch, but I still experienced erratic performance and even data loss on my drives (Intel ICH10R). The Q&A 38 attachment (HD240UI_JP firmware) resolved the issues. As always, YMMV.

Though it may be cosmetic, the Hardware ID in Windows now reads: SAMSUNG_HD204UI_________________________1AQ10003

 

[joeschmuck]

No. I originally used the Q&A 37 patch, but I still experienced erratic performance and even data loss on my drives (Intel ICH10R). The Q&A 38 attachment (HD240UI_JP firmware) resolved the issues. As always, YMMV.

Though it may be cosmetic, the Hardware ID in Windows now reads: SAMSUNG_HD204UI_________________________1AQ10003

Yes, 1AQ10003 is correct based on your posting as it's the version related to the JP patch being applied. Glad the patch helped your situation.

 

[Tekkie]

Also make sure you disable S.M.A.R.T. for these drives, in my system it affected stability and performance.

 

[ProtoSD]

@ Tekkie,

That's really strange about SMART with your drives, I haven't had any trouble with performance or stability with mine and I intentionally have SMART enabled. If you disable SMART, later on when they actually get email warnings working for drive failures you would lose the ability to be notified of a SMART related failure. I just had a drive (Hitachi) start to fail and even though the email didn't work, I did see the SMART error which tipped me off.

I guess if it helped you, that's great. When I got my drives the first thing I did was upgrade the firmware, and it is pretty stupid they didn't change the revision number.

I just thought I'd point out the disadvantage of losing email warnings if there's a SMART failure. (Which doesn't work yet, maybe 8.01 will fix it)

 

[almagest]

@Tekkie: Would you be so kind as to share the production date of the disks (specified on the drivelabels) and which version of Freenas you are running?

Im pouring data in on the disks in a few hours or so, so i will be monitoring carefully.
I guess that after a 100GB or so of writing, and some smartctl -a's during the copy operation, it will be apparent if the patch is working or not.

 

[Milhouse]

For what it's worth, I've been running 4x HD204UI/Z4 since January (purchased 23-Dec-2010, production date appears to be 2010.09) and I applied the F4EG/1AQ10001 firmware update immediately. I haven't had any problems in either FreeNAS 0.7 or FreeNAS 8, and I've probably transferred a cumulative total of about 8TB of data so far (four repeated ~2TB restores) and no hitches. SMART is enabled.

 

[joeschmuck]

My drives are all HD204UI with production dates of 2010.11 and 2010.12 and I applied the F4EG/1AQ10001 firmware within a week of having the drives (once I found out about the update) and have never had a single problem with them. They have been used for FreeNAS 8.x and I used two of them for Windows 7 for a short time and one in a manufactured NAS box for a few months. No problems at all.

One thing the OP was interested in was the 4K sectors and I just wanted to point out (didn't see it above) was that this drive uses 512 byte emulation and you cannot get around it. It appears that when you select 4K sectors what you are really doing is aligning on an even boundary (sector 64). This doesn't change the way the drive transfers data, it's still 512 bytes at a time, not 4Kbytes at a a time. This is for the HD204 models. Does it make a big difference, not really. If you're looking for high speed transfer rates then you would be purchasing enterprise level drives. When I contacted Samsung back in January, they currently have no plans to release a firmware update to remove the emulation from these drives.