From Electron Cloud
Jump to: navigation, search
(New page: My email to Western Digital: {{quote|text=I have a Linux box which I use for MythTV, SqueezeCenter, as a file server etc. The primary drive is a WD5000AAKS and performs quite well, so I us...)
 
Line 16: Line 16:
 
(it should be even faster than the 500 gig drive) but it seems like in normal usage, the seek time is really bad or something. The drive can go for several minutes at a time making rhythmic seek noises, much louder than the other one. While it is doing this, any files stored on that drive are not very accessible - even doing "ls" can take a very long time, as much as half a minute or so. I have not had any data loss though. I don't know what to blame the performance on, but I would bet that if I get a different model of terabyte drive and transfer everything to it, I will see a huge difference in performance. I just wondered if there are some known problems along these lines - something caused by the RAID optimization, or the "green" aspects or something that can be corrected with a firmware update, or maybe it's an actual defect (since I'm reading a lot of reviews about problems with this one, people losing all their data after a day, or a month). If I can still trust this drive not to lose data, maybe I just have to put it in a box and use it for an external backup drive, because it can transfer data reasonably fast as long as there's not too much seeking involved.
 
(it should be even faster than the 500 gig drive) but it seems like in normal usage, the seek time is really bad or something. The drive can go for several minutes at a time making rhythmic seek noises, much louder than the other one. While it is doing this, any files stored on that drive are not very accessible - even doing "ls" can take a very long time, as much as half a minute or so. I have not had any data loss though. I don't know what to blame the performance on, but I would bet that if I get a different model of terabyte drive and transfer everything to it, I will see a huge difference in performance. I just wondered if there are some known problems along these lines - something caused by the RAID optimization, or the "green" aspects or something that can be corrected with a firmware update, or maybe it's an actual defect (since I'm reading a lot of reviews about problems with this one, people losing all their data after a day, or a month). If I can still trust this drive not to lose data, maybe I just have to put it in a box and use it for an external backup drive, because it can transfer data reasonably fast as long as there's not too much seeking involved.
 
}}
 
}}
 +
 +
Then I tried Bonnie++... now it's very obvious there is a performance difference!  On sdb it was crunching for several minutes, on sda for mere seconds.
 +
 +
<TABLE ALIGN=center BORDER=3 CELLPADDING=2 CELLSPACING=1><TR><TD COLSPAN=3 class="header"><FONT SIZE=+1><B>Version 1.93c</B></FONT></TD><TD COLSPAN=6 class="header"><FONT SIZE=+2><B>Sequential Output</B></FONT></TD><TD COLSPAN=4 class="header"><FONT SIZE=+2><B>Sequential Input</B></FONT></TD><TD COLSPAN=2 ROWSPAN=2 class="header"><FONT SIZE=+2><B>Random<BR>Seeks</B></FONT></TD><TD COLSPAN=1 class="header"></TD><TD COLSPAN=6 class="header"><FONT SIZE=+2><B>Sequential Create</B></FONT></TD><TD COLSPAN=6 class="header"><FONT SIZE=+2><B>Random Create</B></FONT></TD></TR>
 +
<TR><TD COLSPAN=2>Concurrency</TD><TD>Size</TD><TD COLSPAN=2>Per Char</TD><TD COLSPAN=2>Block</TD><TD COLSPAN=2>Rewrite</TD><TD COLSPAN=2>Per Char</TD><TD COLSPAN=2>Block</TD><TD>Num Files</TD><TD COLSPAN=2>Create</TD><TD COLSPAN=2>Read</TD><TD COLSPAN=2>Delete</TD><TD COLSPAN=2>Create</TD><TD COLSPAN=2>Read</TD><TD COLSPAN=2>Delete</TD></TR><TR><TD COLSPAN=3></TD><TD class="ksec"><FONT SIZE=-2>K/sec</FONT></TD><TD class="ksec"><FONT SIZE=-2>% CPU</FONT></TD><TD class="ksec"><FONT SIZE=-2>K/sec</FONT></TD><TD class="ksec"><FONT SIZE=-2>% CPU</FONT></TD><TD class="ksec"><FONT SIZE=-2>K/sec</FONT></TD><TD class="ksec"><FONT SIZE=-2>% CPU</FONT></TD><TD class="ksec"><FONT SIZE=-2>K/sec</FONT></TD><TD class="ksec"><FONT SIZE=-2>% CPU</FONT></TD><TD class="ksec"><FONT SIZE=-2>K/sec</FONT></TD><TD class="ksec"><FONT SIZE=-2>% CPU</FONT></TD><TD class="ksec"><FONT SIZE=-2>/sec</FONT></TD><TD class="ksec"><FONT SIZE=-2>% CPU</FONT></TD><TD COLSPAN=1></TD><TD class="ksec"><FONT SIZE=-2>/sec</FONT></TD><TD class="ksec"><FONT SIZE=-2>% CPU</FONT></TD><TD class="ksec"><FONT SIZE=-2>/sec</FONT></TD><TD class="ksec"><FONT SIZE=-2>% CPU</FONT></TD><TD class="ksec"><FONT SIZE=-2>/sec</FONT></TD><TD class="ksec"><FONT SIZE=-2>% CPU</FONT></TD><TD class="ksec"><FONT SIZE=-2>/sec</FONT></TD><TD class="ksec"><FONT SIZE=-2>% CPU</FONT></TD><TD class="ksec"><FONT SIZE=-2>/sec</FONT></TD><TD class="ksec"><FONT SIZE=-2>% CPU</FONT></TD><TD class="ksec"><FONT SIZE=-2>/sec</FONT></TD><TD class="ksec"><FONT SIZE=-2>% CPU</FONT></TD></TR>
 +
<TR><TD bgcolor="#FFFFFF" class="rowheader"><FONT SIZE=+1>neutron</TD><TD class="size" bgcolor="#FFFFFF">1</TD><TD class="size" bgcolor="#FFFFFF">6G</TD><TD>274</TD><TD>98</TD><TD>51301</TD><TD bgcolor="#8B7400">18</TD><TD>26301</TD><TD bgcolor="#54AB00">7</TD><TD>1463</TD><TD bgcolor="#9A6500">96</TD><TD>59167</TD><TD bgcolor="#A85700">9</TD><TD>231.7</TD><TD>3</TD><TD class="size" bgcolor="#FFFFFF">16</TD><TD>15594</TD><TD bgcolor="#00FF00">74</TD><TD>+++++</TD><TD>+++</TD><TD>18589</TD><TD bgcolor="#5AA500">98</TD><TD>18627</TD><TD bgcolor="#7F8000">87</TD><TD>+++++</TD><TD>+++</TD><TD>16965</TD><TD bgcolor="#9D6200" COLSPAN=2>95</TD></TR>
 +
<TR><TD bgcolor="#FFFFFF" class="rowheader"><FONT SIZE=+1>neutron</TD><TD class="size" bgcolor="#FFFFFF" COLSPAN=2>Latency</TD><TD bgcolor="#807F00" COLSPAN=2>57729us</TD><TD bgcolor="#3AC500" COLSPAN=2>4414ms</TD><TD bgcolor="#00FF00" COLSPAN=2>1220ms</TD><TD bgcolor="#EC1300" COLSPAN=2>51215us</TD><TD bgcolor="#00FF00" COLSPAN=2>214ms</TD><TD bgcolor="#00FF00" COLSPAN=2>282ms</TD><TD class="size" bgcolor="#FFFFFF" COLSPAN=1>Latency</TD><TD bgcolor="#00FF00" COLSPAN=2>17607us</TD><TD bgcolor="#FF0000" COLSPAN=2>10673us</TD><TD bgcolor="#00FF00" COLSPAN=2>3077us</TD><TD bgcolor="#FF0000" COLSPAN=2>38672us</TD><TD bgcolor="#00FF00" COLSPAN=2>755us</TD><TD>14265us</TD></TR>
 +
<TR><TD bgcolor="#FFFFFF" class="rowheader"><FONT SIZE=+1>neutron</TD><TD class="size" bgcolor="#FFFFFF">1</TD><TD class="size" bgcolor="#FFFFFF">6G</TD><TD>237</TD><TD>98</TD><TD>36724</TD><TD bgcolor="#A05F00">17</TD><TD>20134</TD><TD bgcolor="#CE3100">5</TD><TD>1391</TD><TD bgcolor="#926D00">98</TD><TD>63035</TD><TD bgcolor="#827D00">10</TD><TD>30.4</TD><TD>1</TD><TD class="size" bgcolor="#FFFFFF">16</TD><TD>45</TD><TD bgcolor="#FF0000">1</TD><TD>+++++</TD><TD>+++</TD><TD>13180</TD><TD bgcolor="#C93600">72</TD><TD>5579</TD><TD bgcolor="#AB5400">77</TD><TD>+++++</TD><TD>+++</TD><TD>12702</TD><TD bgcolor="#3EC100" COLSPAN=2>73</TD></TR>
 +
<TR><TD bgcolor="#FFFFFF" class="rowheader"><FONT SIZE=+1>neutron</TD><TD class="size" bgcolor="#FFFFFF" COLSPAN=2>Latency</TD><TD bgcolor="#56A900" COLSPAN=2>51377us</TD><TD bgcolor="#A25D00" COLSPAN=2>5875ms</TD><TD bgcolor="#FF0000" COLSPAN=2>3985ms</TD><TD bgcolor="#0BF400" COLSPAN=2>27709us</TD><TD bgcolor="#FF0000" COLSPAN=2>1970ms</TD><TD bgcolor="#FF0000" COLSPAN=2>3581ms</TD><TD class="size" bgcolor="#FFFFFF" COLSPAN=1>Latency</TD><TD bgcolor="#FF0000" COLSPAN=2>293s</TD><TD bgcolor="#00FF00" COLSPAN=2>313us</TD><TD bgcolor="#FF0000" COLSPAN=2>212ms</TD><TD bgcolor="#00FF00" COLSPAN=2>12460us</TD><TD bgcolor="#FF0000" COLSPAN=2>12142us</TD><TD>11643us</TD></TR>
 +
</TABLE>
 +
 +
 +
Both drives are formatted with ReiserFS.
 +
<pre>
 +
/tmp
 +
[neutron][02:33:27 PM] fdisk -l /dev/sda
 +
 +
Disk /dev/sda: 500.1 GB, 500107862016 bytes
 +
255 heads, 63 sectors/track, 60801 cylinders
 +
Units = cylinders of 16065 * 512 = 8225280 bytes
 +
Disk identifier: 0x8e9c8e9c
 +
 +
  Device Boot      Start        End      Blocks  Id  System
 +
/dev/sda1  *          1        7296    58605088+  7  HPFS/NTFS
 +
/dev/sda2            7297        7298      16065  83  Linux
 +
/dev/sda3            7299        7664    2939895  82  Linux swap / Solaris
 +
/dev/sda4            7665      60801  426822952+  5  Extended
 +
/dev/sda5            7665      10097    19543041  83  Linux
 +
/dev/sda6          10098      60801  407279848+  83  Linux
 +
 +
/tmp
 +
[neutron][02:34:12 PM] fdisk -l /dev/sdb
 +
 +
Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
 +
255 heads, 63 sectors/track, 121601 cylinders
 +
Units = cylinders of 16065 * 512 = 8225280 bytes
 +
Disk identifier: 0x00000000
 +
 +
  Device Boot      Start        End      Blocks  Id  System
 +
/dev/sdb1              1      121601  976760001  83  Linux
 +
</pre>

Revision as of 15:21, 18 January 2009

My email to Western Digital:

I have a Linux box which I use for MythTV, SqueezeCenter, as a file server etc. The primary drive is a WD5000AAKS and performs quite well, so I use a large partition on it for the MythTV recordings. Later I added this WD1000FYPS for longer-term file storage, and I've always been dissatisfied with the performance. It's strange, because hdparm reports good results:

[neutron][01:34:48 PM] hdparm -tT /dev/sda

/dev/sda: Timing cached reads: 1974 MB in 2.00 seconds = 986.64 MB/sec Timing buffered disk reads: 198 MB in 3.01 seconds = 65.70 MB/sec

[neutron][01:49:00 PM] hdparm -tT /dev/sdb

/dev/sdb: Timing cached reads: 2160 MB in 2.00 seconds = 1080.53 MB/sec Timing buffered disk reads: 224 MB in 3.02 seconds = 74.22 MB/sec

(it should be even faster than the 500 gig drive) but it seems like in normal usage, the seek time is really bad or something. The drive can go for several minutes at a time making rhythmic seek noises, much louder than the other one. While it is doing this, any files stored on that drive are not very accessible - even doing "ls" can take a very long time, as much as half a minute or so. I have not had any data loss though. I don't know what to blame the performance on, but I would bet that if I get a different model of terabyte drive and transfer everything to it, I will see a huge difference in performance. I just wondered if there are some known problems along these lines - something caused by the RAID optimization, or the "green" aspects or something that can be corrected with a firmware update, or maybe it's an actual defect (since I'm reading a lot of reviews about problems with this one, people losing all their data after a day, or a month). If I can still trust this drive not to lose data, maybe I just have to put it in a box and use it for an external backup drive, because it can transfer data reasonably fast as long as there's not too much seeking involved.

Then I tried Bonnie++... now it's very obvious there is a performance difference! On sdb it was crunching for several minutes, on sda for mere seconds.

Version 1.93cSequential OutputSequential InputRandom
Seeks
Sequential CreateRandom Create
ConcurrencySizePer CharBlockRewritePer CharBlockNum FilesCreateReadDeleteCreateReadDelete
K/sec% CPUK/sec% CPUK/sec% CPUK/sec% CPUK/sec% CPU/sec% CPU/sec% CPU/sec% CPU/sec% CPU/sec% CPU/sec% CPU/sec% CPU
neutron</TD>1</TD>6G</TD>274</TD>98</TD>51301</TD>18</TD>26301</TD>7</TD>1463</TD>96</TD>59167</TD>9</TD>231.7</TD>3</TD>16</TD>15594</TD>74</TD>+++++</TD>+++</TD>18589</TD>98</TD>18627</TD>87</TD>+++++</TD>+++</TD>16965</TD>95</TD></TR>
neutron</TD>Latency</TD>57729us</TD>4414ms</TD>1220ms</TD>51215us</TD>214ms</TD>282ms</TD>Latency</TD>17607us</TD>10673us</TD>3077us</TD>38672us</TD>755us</TD>14265us</TD></TR>
neutron</TD>1</TD>6G</TD>237</TD>98</TD>36724</TD>17</TD>20134</TD>5</TD>1391</TD>98</TD>63035</TD>10</TD>30.4</TD>1</TD>16</TD>45</TD>1</TD>+++++</TD>+++</TD>13180</TD>72</TD>5579</TD>77</TD>+++++</TD>+++</TD>12702</TD>73</TD></TR>
neutron</TD>Latency</TD>51377us</TD>5875ms</TD>3985ms</TD>27709us</TD>1970ms</TD>3581ms</TD>Latency</TD>293s</TD>313us</TD>212ms</TD>12460us</TD>12142us</TD>11643us</TD></TR>

</TABLE>


Both drives are formatted with ReiserFS.

/tmp
[neutron][02:33:27 PM] fdisk -l /dev/sda

Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x8e9c8e9c

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1        7296    58605088+   7  HPFS/NTFS
/dev/sda2            7297        7298       16065   83  Linux
/dev/sda3            7299        7664     2939895   82  Linux swap / Solaris
/dev/sda4            7665       60801   426822952+   5  Extended
/dev/sda5            7665       10097    19543041   83  Linux
/dev/sda6           10098       60801   407279848+  83  Linux

/tmp
[neutron][02:34:12 PM] fdisk -l /dev/sdb

Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1      121601   976760001   83  Linux