Samsung Spinpoint F1 vs. WD Green - which is better for parity?

[Rajahal]

So I just ordered a Samsung Spinpoint F1.  I've never had a Samsung drive before, but I've read good things about them here and at Newegg.  My unRAID server is currently using a WD Green 1TB drive as a parity drive.  Since the Samsung is a 7200 rpm drive, and the WD Green is a variable speed 5400 - 7200 rpm drive, I'm wondering if I might see a performance improvement (in write operations and parity checks) by swapping out the WD with the Samsung as my parity drive.  I would then add the WD drive to the array as a data drive.  What do you guys and gals think?

[Joe L.]

So I just ordered a Samsung Spinpoint F1.  I've never had a Samsung drive before, but I've read good things about them here and at Newegg.  My unRAID server is currently using a WD Green 1TB drive as a parity drive.  Since the Samsung is a 7200 rpm drive, and the WD Green is a variable speed 5400 - 7200 rpm drive, I'm wondering if I might see a performance improvement (in write operations and parity checks) by swapping out the WD with the Samsung as my parity drive.  I would then add the WD drive to the array as a data drive.  What do you guys and gals think?

I'm not so sure you have a variable speed drive.  There have been many reports that the marketing materials were deliberately misleading.

 

from the article:

 

"The Western Digital Green Power Caviar 2TB drive features 4 - 500GB platters rotating at a variable speed that is determined by the transfer rate required at any given time. Due to this variable spindle speed Western Digital has not published any rotational speed specifics. "

 

I cannot believe "journalists" are STILL making this mistake

 

NONE of the GP drive VARY their spin speed - this would be INCREDIBLY difficult to achieve!!!  Each drive has a fixed speed - so far they are ALL very very close to 5400rpm (its easy to measure the spin speed with an oscilliscope and "listen" to the hum of the drive) - and even under very very heavy load - the spin speeds dont change, at all.

Even another hot hardware article says:

 

" We know that they are likely spinning at a speed between 5400 and 7200 RPM and that each GreenPower model may use a different, invariable RPM."

[RobJ]

I would agree that, on paper at least, your parity-protected writes should be faster with the faster parity drive.  I would thoroughly PreClear the new Samsung first though, before going to the trouble of swapping a perfectly good parity drive out.

[WeeboTech]

Since the drive rotates faster and has twice the amount of cache, You should notice a change in parity protected writes immediately.

If you do not I would be surprised. I'm not sure how much of a difference you will see, but it should be noticeable.

 

I switched to a Seagate 1.5TB drive for parity and saw the performance jump up immediately.

 

it wasn't like having a new server, however, many prior tasks with long latency now seemed much snappier.

 

 

 

 

[Rajahal]

I'm not so sure you have a variable speed drive.   There have been many reports that the marketing materials were deliberately misleading.

Huh, interesting.  Even still, the WD Green drive is definitely less than 7200 rpm, and likely close to 5400 rpm (5900 rpm maybe?  I've read about that as a viable rotational speed).  So it is slower than the F1.

 

I would agree that, on paper at least, your parity-protected writes should be faster with the faster parity drive.  I would thoroughly PreClear the new Samsung first though, before going to the trouble of swapping a perfectly good parity drive out.

 

Thanks for the input, that was my thought exactly.  Good call with the PreClear script too - I haven't used it yet, but I suppose its time I learn.

 

WeeboTech: That's what I'm hoping will happen, I'll let you know when the new drive arrives!

 

Is there any easy (emphasis on 'easy') way to replace a parity drive without losing parity protection?  I know the standard method will force the server to recalculate all parity info, which will temporarily put me at risk of losing data due to a singe drive failure.  I don't really mind taking this small risk, especially considering all my most important (irreplaceable) data is now backed up with CrashPlan, but of course if there is no reason to take that risk, then I would rather not.

[Joe L.]

Here is another reference:

http://forums.macrumors.com/showpost.php?s=bcceb9fa25691df960520dac43ebfa7c&p=5162172&postcount=5

 

No, not variable speeds, but possibility of different speeds marketed under the same "Green" logo.

 

Joe L.

[RobJ]

Is there any easy (emphasis on 'easy') way to replace a parity drive without losing parity protection?  I know the standard method will force the server to recalculate all parity info, which will temporarily put me at risk of losing data due to a singe drive failure.  I don't really mind taking this small risk, especially considering all my most important (irreplaceable) data is now backed up with CrashPlan, but of course if there is no reason to take that risk, then I would rather not.

 

Unless I am forgetting something, I don't see any risk here, because you still have the original parity drive, easily put back online if something goes wrong during the new parity sync.  For safety, I would disallow any modifications to the array, until the new parity drive is ready.  The easiest way to do that is just disconnect the network cable.

 

Of course, it is always wise to have important data multiply backed up.

[Rajahal]

Is there any easy (emphasis on 'easy') way to replace a parity drive without losing parity protection?  I know the standard method will force the server to recalculate all parity info, which will temporarily put me at risk of losing data due to a singe drive failure.  I don't really mind taking this small risk, especially considering all my most important (irreplaceable) data is now backed up with CrashPlan, but of course if there is no reason to take that risk, then I would rather not.

 

Unless I am forgetting something, I don't see any risk here, because you still have the original parity drive, easily put back online if something goes wrong during the new parity sync.  For safety, I would disallow any modifications to the array, until the new parity drive is ready.   The easiest way to do that is just disconnect the network cable.

 

Of course, it is always wise to have important data multiply backed up.

 

Ah yes, very true, I forgot about that.  Well then, as soon as the drive gets here, I'm ready to go.

[Joe L.]

Is there any easy (emphasis on 'easy') way to replace a parity drive without losing parity protection?  I know the standard method will force the server to recalculate all parity info, which will temporarily put me at risk of losing data due to a singe drive failure.  I don't really mind taking this small risk, especially considering all my most important (irreplaceable) data is now backed up with CrashPlan, but of course if there is no reason to take that risk, then I would rather not.

 

Unless I am forgetting something, I don't see any risk here, because you still have the original parity drive, easily put back online if something goes wrong during the new parity sync.  For safety, I would disallow any modifications to the array, until the new parity drive is ready.   The easiest way to do that is just disconnect the network cable.

 

Of course, it is always wise to have important data multiply backed up.

 

Ah yes, very true, I forgot about that.  Well then, as soon as the drive gets here, I'm ready to go.

Even though you do not explicitly write to the drives, they are written to every time they are mounted or un-mounted.

To verify, all you need to do is look at the read/write statistics as soon as you reboot.  Now, these "writes" are not as likely to corrupt your data, but they will make the parity drive slightly out-of-date for those housekeeping bytes tracking mount status and time.

 

It is far far far better to put the new drive through a multi pre-clear cycle before putting it to use in your array.  It will give you a lot more confidence in its ability to work properly and not suffer an early failure.  The zeroing of the drive will not be of any help when replacing the parity drive, but the massive amount of reads/writes will prove the surface has no bad sectors. (or a minimal amount)

 

Joe L.

[Rajahal]

ACK!  Foiled again! 

 

unRAID won't allow me to make the Samsung drive the parity drive because it is slightly smaller than the 2 WD Green drives also in the array, so I get the 'drive in parity slot is not the biggest' error.  The Samsung is something on the order of a few MBs smaller, not a big enough difference to have any real-world impact, but enough to screw with unRAID.  I've noticed this before with my slew of 500 GB drives, they are not all the same size (since some are WD and some are Seagate).

 

Any suggestions, oh exalted unRAID gurus?  I can't be the first person to have run into this problem.

 

Edit: I should have just gone for the WD Black.  It would have saved me many headaches.

[RobJ]

You have a Gigabyte motherboard, and the difference is about 2MB, so that is almost certainly the Gigabyte HPA, grabbed (without permission) for BIOS backup.  It would have happened to ANY drive added to a low SATA slot on the motherboard.  You can confirm this in the syslog where the drive is first identified, look for HPA, with a sector difference of 2113 less than actual.

 

If you can move this drive to a fast addon card, or to the last possible SATA onboard port, then you can use the MHDD tool mentioned by cepler in your other thread to remove the HPA from this drive, make sure you reboot after running it.  Before removing this HPA, locate another drive that already has the HPA (check your syslog), and reconnect it to the first onboard SATA port, and reboot.  This *should* keep the Gigabyte happy, and stop it from putting the HPA on any other drives, since you are going to get one anyway.

[Rajahal]

Thanks for the tip, RobJ.  I'll take a look at the syslog tonight, and look for the HPA info.  If everything matches up to what you explained, then I'll try the MHDD tool.

 

So the problem isn't manufacturer-specific?  I thought it was since I've noticed that all my Seagate 500 GB drives have the same reported capacity, whereas the WD 500 GB drive is slightly different.  Same goes for my two 1 TB WD Green drives versus the 1 TB Samsung.  So that trend is just coincidence?

 

I don't have any fast addon cards, just the Promise TX4 (PCI).  My server is configured like this:

Onboard SATA (4 SATA ports): 1 TB Samsung (intended parity), 2 x 1 TB WD Green (intended data), 320 GB Seagate (cache)

Promise TX4 PCI card (4 SATA ports): 640 GB WD (data), 2 x 500 GB Seagate (data), 500 GB WD (data)

 

So the new Samsung drive is already connected directly to the mobo, but I don't remember which slot it is using (I didn't know it mattered).  By 'last possible SATA onboard port' I'm guessing you mean slot 4 of 4?

 

Edit: I can't telnet into my server!  I haven't changed the name, it is still the default 'tower'.  I'm following the instructions here.  I go to Start > Run and type in 'telnet tower', and get the error "Windows cannot find 'telnet'.  Make sure you typed the name correctly, then try again."  What am I doing wrong?  I have added a password to the 'root' account, does that change anything?  I also looked into getting PuTTy, but apparently I can't run it since I'm on a 64 bit AMD machine (and it says Intel x86 only).

 

Edit2: Hmm, well, I installed PuTTy on my Intel-based 32 bit laptop, and I seem to be able to log in to the server from here.  I would still like to be able to telnet or PuTTy in to the server from my desktop, though, so I would still appreciate any help getting that working.

 

Edit3: I have attached my syslog (copied from PuTTy).  I don't see anything about HPA.  Would you kindly take a look at it and tell me if you see anything odd?  Oh, and the difference between the WD Green drives and the Samsung is 1056, so less than 2 MB as you predicted.

[jk2587]

Edit: I can't telnet into my server!  I haven't changed the name, it is still the default 'tower'.  I'm following the instructions here.  I go to Start > Run and type in 'telnet tower', and get the error "Windows cannot find 'telnet'.  Make sure you typed the name correctly, then try again."  What am I doing wrong?  I have added a password to the 'root' account, does that change anything?  I also looked into getting PuTTy, but apparently I can't run it since I'm on a 64 bit AMD machine (and it says Intel x86 only).

 

Edit2: Hmm, well, I installed PuTTy on my Intel-based 32 bit laptop, and I seem to be able to log in to the server from here.  I would still like to be able to telnet or PuTTy in to the server from my desktop, though, so I would still appreciate any help getting that working.

 

I'm guessing you're using Vista or Win7, which does not have the telnet client installed by default. You can install it from Control Panel > Programs > Turn Windows Features on or off.

 

[RobJ]

I have attached my syslog (copied from PuTTy).  I don't see anything about HPA.  Would you kindly take a look at it and tell me if you see anything odd?

Unfortunately, that is only the last 14K of the full syslog, usually about 60K to 70K.  All of the drive identification and setup occurred earlier in the syslog.  Please see the Troubleshooting link in my sig for the correct way to capture the full syslog.

 

Oh, and the difference between the WD Green drives and the Samsung is 1056, so less than 2 MB as you predicted.

That was careless of me, the difference is about 1MB.  It's actually a difference of 2113 sectors (LBA, 512 byte) that corresponds to the difference of 1056 1K blocks.

 

Side note:  It has always bothered me that 2113 sectors corresponds to 1056 1K blocks.  If a 1K block is 2 sectors, then that equals 2112 sectors, not 2113.  And as anyone knows that has ever dealt with sectors and clusters (no matter how you define them), if you use even one byte of a cluster, then all of the sectors of that cluster have to be marked as Used.  So technically it seems to me that the true difference should be 1057, not 1056.  I'd love to hear from anyone that can explain this.  (and if I did something really stupid, please be kind!)

 

So the problem isn't manufacturer-specific?  I thought it was since I've noticed that all my Seagate 500 GB drives have the same reported capacity, whereas the WD 500 GB drive is slightly different.  Same goes for my two 1 TB WD Green drives versus the 1 TB Samsung.  So that trend is just coincidence?

 

I don't have any fast addon cards, just the Promise TX4 (PCI).  My server is configured like this:

Onboard SATA (4 SATA ports): 1 TB Samsung (intended parity), 2 x 1 TB WD Green (intended data), 320 GB Seagate (cache)

Promise TX4 PCI card (4 SATA ports): 640 GB WD (data), 2 x 500 GB Seagate (data), 500 GB WD (data)

Jul 16 21:23:00 Tower emhttp: pci-0000:00:08.0-scsi-0:0:0:0 (sde) ata-SAMSUNG_HD103UJ_S13PJ1LS631384
Jul 16 21:23:00 Tower emhttp: pci-0000:00:08.0-scsi-1:0:0:0 (sdf) ata-WDC_WD6400AAKS-75A7B0_WD-WMASY2219732
Jul 16 21:23:00 Tower emhttp: pci-0000:00:08.1-scsi-0:0:0:0 (sdh) ata-WDC_WD10EADS-00L5B1_WD-WCAU45951367
Jul 16 21:23:00 Tower emhttp: pci-0000:00:08.1-scsi-1:0:0:0 (sdi) ata-WDC_WD10EADS-00L5B1_WD-WCAU49026373
Jul 16 21:23:00 Tower emhttp: pci-0000:01:06.0-scsi-0:0:0:0 (sda) ata-ST3320620AS_6QF0WRZW
Jul 16 21:23:00 Tower emhttp: pci-0000:01:06.0-scsi-1:0:0:0 (sdb) ata-ST3500630AS_5QG09A5Q
Jul 16 21:23:00 Tower emhttp: pci-0000:01:06.0-scsi-2:0:0:0 (sdc) ata-ST3500630AS_5QG0ZN8S
Jul 16 21:23:00 Tower emhttp: pci-0000:01:06.0-scsi-3:0:0:0 (sdd) ata-WDC_WD5000AAJS-22TKA0_WD-WCAPW5380433

Even without the rest of the syslog, you can see above that there are 2 disk controllers in use, associated with pci-0000:00:08 (onboard) and pci-0000:01:06 (TX4), and each has 4 drives connected.  And you can see that the Samsung (sde) is on the first onboard port.

Jul 16 21:23:00 Tower kernel: md: import disk0: [8,112] (sdh) WDC WD10EADS-00L5B1      WD-WCAU45951367  offset: 63  size: 976762552
Jul 16 21:23:00 Tower kernel: md: import disk1: [8,48]  (sdd) WDC WD5000AAJS-22TKA0    WD-WCAPW5380433  offset: 63  size: 488385496
Jul 16 21:23:00 Tower kernel: md: import disk2: [8,64]  (sde) SAMSUNG HD103UJ           S13PJ1LS631384  offset: 63  size: 976761496
Jul 16 21:23:00 Tower kernel: md: import disk3: [8,32]  (sdc) ST3500630AS                     5QG0ZN8S  offset: 63  size: 488386552
Jul 16 21:23:00 Tower kernel: md: import disk5: [8,16]  (sdb) ST3500630AS                     5QG09A5Q  offset: 63  size: 488386552
Jul 16 21:23:00 Tower kernel: md: import disk6: [8,80]  (sdf) WDC WD6400AAKS-75A7B0    WD-WMASY2219732  offset: 63  size: 625131832
Jul 16 21:23:00 Tower kernel: md: import disk7: [8,128] (sdi) WDC WD10EADS-00L5B1      WD-WCAU49026373  offset: 63  size: 976762552

And here you can see that the Samsung appears to be HPA shortened by 1056, compared to the 2 WD 1TB drives, and the WD 500GB drive appears to be HPA shortened by 1056, compared to the 2 Seagate 500GB drives.  Although the WD 500GB is now connected to the TX4, I would almost bet that at one time, it was connected to a low onboard port.  I'm not sure about the WD 640GB, but the syslog will confirm whether it too has been HPA shortened.  If it has, then it would be the best drive to reconnect to the first SATA onboard port.

 

Now to clear up some confusion on my part, I may have mixed up threads between several users but I thought you said that you wanted the Samsung for the parity drive, but got the drive-too-small error.  Above, the array looks fine as is, with a good full size parity drive and the Samsung as data Disk 2.  Were you wanting to swap the drives?

 

By 'last possible SATA onboard port' I'm guessing you mean slot 4 of 4?

Correct.

[Rajahal]

jk2587: Thank you for the insight, I'm sure you are right, I'll install telnet on my Vista x64 machine tonight.

 

RobJ: Thank you, as always, for your incredibly detailed and helpful response.  Sorry about the syslog mishap (it's my first time!), I'll post the full syslog tonight when I get home.  I've switched around my drives a LOT, so I'm sure you are right that the 500 GB WD was at one point connected directly to the mobo. 

 

I have just two questions at this point:

 

I'm not sure about the WD 640GB, but the syslog will confirm whether it too has been HPA shortened.  If it has, then it would be the best drive to reconnect to the first SATA onboard port.

I think I see your point here, that since the WD 640GB drive is likely already HPA shortened (yes, it has been directly connected to the mobo in the past), I should put it in the motherboard's SATA slot 1 so that the mobo will see it first and then not need to HPA any other drives.  However, I would like to avoid doing this, since I believe it will slow down my system a bit (please correct me if I'm wrong here).  Since I only have 4 onboard SATA ports, I'm reserving them for my fastest and most used drives, which are:

 

(sde) ata-SAMSUNG_HD103UJ_S13PJ1LS631384 - 1 TB (intended parity, currently data)

(sdh) ata-WDC_WD10EADS-00L5B1_WD-WCAU45951367 - 1 TB Green (currently parity, intended data)

(sdi) ata-WDC_WD10EADS-00L5B1_WD-WCAU49026373 - 1 TB Green (data)

(sda) ata-ST3320620AS_6QF0WRZW - 320 GB cache drive

 

The 320 GB drive is actually my oldest, slowest, and smallest drive, but since I'm using it as a cache drive, I figured my server's performance would benefit by putting it directly on the mobo.  Is this correct?  If I won't notice the PCI bottleneck by moving it onto the TX4 card, I certainly don't mind doing it (and really, I would kind of prefer it, since then more of my data drives could be connected to the mobo).

 

Now to clear up some confusion on my part, I may have mixed up threads between several users but I thought you said that you wanted the Samsung for the parity drive, but got the drive-too-small error.  Above, the array looks fine as is, with a good full size parity drive and the Samsung as data Disk 2.  Were you wanting to swap the drives?

You remembered correctly, this is exactly the situation.  I do still want to swap the drives (to optimize performance), however, my lazy side is getting stronger and stronger by the day.  I'm considering just leaving it as it is, dealing with the slightly slower parity operations for a while (I don't really even notice them, since I'm using a cache drive), and making sure that the next drive I purchase is larger than 1 TB (guess it would have to be 1.5 TB or greater, wish there was a 1.25 TB size!).

 

If only there were some quick way to remove HPA from all drives without screwing anything up.  Perhaps something like that could be added to the PreClear script?  Just a thought.  Again, I'll post my full syslog later tonight.

 

Edit: Sorry, didn't have a chance to mess with this last night, I'll try again tonight.

[Rajahal]

Here's the full syslog.  It seems to be non-word wrapped, is that normal?  It gives me a headache just looking at it.

 

E: Oh, uploading it here fixed it.  Weird.

[Rajahal]

Polite bump.