Re: [SOLVED] Is squeeze compatible with WD20EARS and other 2TB drives?
#include hallo.h * Stan Hoeppner [Sun, Jan 16 2011, 01:22:28PM]: of native 4k sectors used with a smaller transfer size. But the whole system programing domain has tons of similar situations. Transfer size? SAS and SATA are both capable of large multi sector transfers. This has nothing to do with transfer size, but SECTOR size. It seems you lack basic understanding of the technology we're discussing. Do you realize that transfer size is an abstract term? Doesn't look so because you obviously fail to make the connection to the subsequent example. And sorry for crushing your theory but you are wrong; usually I wasn't sleeping in related CS lectures. Me stating that these drives suck with Linux (fact) is, to some owners of said drives, apparently akin to me calling their sister fat or mother ugly. And if you are looking for things that suck then remember the bad old days (if you were with us at that time). When you needed to install emulation software like Ontrack to make your harddrive work with DOS and then patch the Linux kernel to get along with it. Or had to write modelines manually because other the monitor might go up in smoke. Or needed to make experiments with hdparm to find the fastest Multiword-DMA mode that still worked with your HDD. Etcetera, etcetera. The problems with AF are a joke. Regards, Eduard. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110120001911.ga22...@rotes76.wohnheim.uni-kl.de
Re: [SOLVED] Is squeeze compatible with WD20EARS and other 2TB drives?
#include hallo.h * Stan Hoeppner [Wed, Jan 12 2011, 10:28:40AM]: Stefan Monnier put forth on 1/11/2011 9:46 PM: I have no idea what makes you so angry against green drives. I am against using any drive, at this time, in Linux, with a native sector size other than 512 bytes. Again, I fail to see why you're so emotional about it. You've got that backwards. You own a bunch of these drives and feel I am That's not my impression. The only good argument I could identify in YOUR answers is the strong (personal) dislike of native 4k sectors used with a smaller transfer size. But the whole system programing domain has tons of similar situations. Why don't you object to 32bit/64bit PCs? They work with small transfer bytes (bytes) but they native WORD size is a lot bigger nowadays. How dare they to do a such thing? Maybe you should consider throwing your PC away right now and buy a modern 8088 XT system from some garage sale. Regards, Eduard. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110116115239.ga10...@rotes76.wohnheim.uni-kl.de
Re: [SOLVED] Is squeeze compatible with WD20EARS and other 2TB drives?
Dne, 16. 01. 2011 07:04:47 je Stefan Monnier napisal(a): I'm down on these drives due to the maniacal 8 second head park interval, which likely does more mechanical damage than it saves power in dollar terms. There is simply no concrete evidence to back this urban legend. In the WD20EARS I purchased this was in no way just a legend -- be it urban or rural or otherwise. I'd be really surprised if you had evidence that your drive failed because of mechanical damage due to aggressive head-park. And if your drive failed while still young, well that happens to the best of the drives, and is no evidence that those drives fail more often than others and even less that if they do it's due to the aggressive head-park. I was referring to the first part of the sentence, namely that the 8-second head park interval was not an urban legend. The drive I got came with the factory setting of 8 seconds. I was not referring to the second part (about it doing more mechanical damage than saving power), although I do see a point there. I see your point too, and while I wouldn't go as far as calling it an urban legend, I'd definitely say it's largely a matter of perspective. From my perspective, power saving was not the primary concern; I purchased the drive hoping it would turn out to be 1. quiet enough; 2. reasonably durable, given its slowish rotational speed; and 3. having an optimal per-gigabyte price. -- Cheerio, Klistvud http://bufferoverflow.tiddlyspot.com Certifiable Loonix User #481801 Please reply to the list, not to me. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1295181442.6034.0@compax
Re: [SOLVED] Is squeeze compatible with WD20EARS and other 2TB drives?
Eduard Bloch put forth on 1/16/2011 5:52 AM: #include hallo.h * Stan Hoeppner [Wed, Jan 12 2011, 10:28:40AM]: Stefan Monnier put forth on 1/11/2011 9:46 PM: I have no idea what makes you so angry against green drives. I am against using any drive, at this time, in Linux, with a native sector size other than 512 bytes. Again, I fail to see why you're so emotional about it. You've got that backwards. You own a bunch of these drives and feel I am That's not my impression. The only good argument I could identify in YOUR answers is the strong (personal) dislike I have no axe to grind with the translation taking place at the drive level. There's nothing technically wrong with it. My axe grinding regards the Linux partitioning utilities and their current inability to properly handle proper sector alignment of such devices without users being required to jump through hoops. I've made that perfectly clear now on multiple occasions on this list. of native 4k sectors used with a smaller transfer size. But the whole system programing domain has tons of similar situations. Transfer size? SAS and SATA are both capable of large multi sector transfers. This has nothing to do with transfer size, but SECTOR size. It seems you lack basic understanding of the technology we're discussing. Why don't you object to 32bit/64bit PCs? They work with small transfer bytes (bytes) but they native WORD size is a lot bigger nowadays. How dare they to do a such thing? Because they work properly out of the box and don't cause headaches for the entirety of a subset (Linux) of users of the technology. But again, your analogy isn't apt. Maybe you should consider throwing your PC away right now and buy a modern 8088 XT system from some garage sale. Lemme guess: you also own one of these drives, don't you? It's amazing to me how many children there are in the world of adults these days. Me stating that these drives suck with Linux (fact) is, to some owners of said drives, apparently akin to me calling their sister fat or mother ugly. My $deity people, thicken your skin for Pete's sake... Eduard, grow up. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d334574.3080...@hardwarefreak.com
Re: [SOLVED] Is squeeze compatible with WD20EARS and other 2TB drives?
In 4d334574.3080...@hardwarefreak.com, Stan Hoeppner wrote: Me stating that these drives suck with Linux (fact) The way you are using suck there is fairly subjective, so I'd be cautious is claiming your statement was fact. The fact is that these drive require more effort (research, special tools, manual alignment, whatever) on the part of each user in order to get performance of cheaper, earlier generation drives. That fact is enough for me to form the opinion that these drive suck with Linux and feel justified in said opinion. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: [SOLVED] Is squeeze compatible with WD20EARS and other 2TB drives?
Boyd Stephen Smith Jr. put forth on 1/16/2011 1:36 PM: In 4d334574.3080...@hardwarefreak.com, Stan Hoeppner wrote: Me stating that these drives suck with Linux (fact) The way you are using suck there is fairly subjective, so I'd be cautious is claiming your statement was fact. The fact is that these drive require more effort (research, special tools, manual alignment, whatever) on the part of each user in order to get performance of cheaper, earlier generation drives. That fact is enough for me to form the opinion that these drive suck with Linux and feel justified in said opinion. Since it's not the advanced format drives at fault, but Linux, I guess I should reverse the two and say from now on: Linux sucks with these drives. Specifically regarding the WD20EARS drives, however, they suck all around. I've already given the myriad reasons why in previous posts. It's the only advanced format drive I've seen constant complaints about on multiple mailing lists. An OP at UC Santa Cruz had 4 of these suckers in his D2D backup server simultaneously die on him just when he needed them most: to do a restore on a 60TB production array that suffered partial catastrophic failure. I've never personally touched a WD advanced format drive, Green line, etc. I've seen too much disappointment and frustration from others to get near one. I'm a happy owner of some Blue series drives, and I'm not seeing negative reports on the Black drives. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d3359c0.6040...@hardwarefreak.com
Re: [SOLVED] Is squeeze compatible with WD20EARS and other 2TB drives?
On Sun, 16 Jan 2011, Stan Hoeppner wrote: I have no axe to grind with the translation taking place at the drive level. There's nothing technically wrong with it. My axe grinding regards the Linux partitioning utilities and their current inability to properly handle proper sector alignment of such devices without users being required to jump through hoops. I've made that perfectly clear now on multiple occasions on this list. It has been mostly fixed on the squeeze installer. I don't think the utilities will all do the right thing by default, though. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110117013036.ga13...@khazad-dum.debian.net
Re: [SOLVED] Is squeeze compatible with WD20EARS and other 2TB drives?
I'm down on these drives due to the maniacal 8 second head park interval, which likely does more mechanical damage than it saves power in dollar terms. There is simply no concrete evidence to back this urban legend. In the WD20EARS I purchased this was in no way just a legend -- be it urban or rural or otherwise. I'd be really surprised if you had evidence that your drive failed because of mechanical damage due to aggressive head-park. And if your drive failed while still young, well that happens to the best of the drives, and is no evidence that those drives fail more often than others and even less that if they do it's due to the aggressive head-park. Stefan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jwv39ottmgy.fsf-monnier+gmane.linux.debian.u...@gnu.org
HD manufacturers and Free Software (was: [SOLVED] Is squeeze compatible with WD20EARS and other 2TB drives?)
MUST READ: Western Digital is unable to provide support for the Unix/Linux operating systems outside of jumper configurations (for EIDE hard drives) and physical installation support. While I never expect any OS-specific support from hard-drive suppliers, I find it offensive for a manufacturer to explicitly single out the OS I use, indeed. So, to get back to Debian, I wonder which manufacturers are more friendly to Free Software (e.g. provides tools to update their drives's firmware from systems like Debian). Stefan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jwvwrm5s7px.fsf-monnier+gmane.linux.debian.u...@gnu.org
Re: [SOLVED] Is squeeze compatible with WD20EARS and other 2TB drives?
Dne, 12. 01. 2011 04:46:42 je Stefan Monnier napisal(a): I'm down on these drives due to the maniacal 8 second head park interval, which likely does more mechanical damage than it saves power in dollar terms. There is simply no concrete evidence to back this urban legend. In the WD20EARS I purchased this was in no way just a legend -- be it urban or rural or otherwise. -- Cheerio, Klistvud http://bufferoverflow.tiddlyspot.com Certifiable Loonix User #481801 Please reply to the list, not to me. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1294826470.720...@compax
Re: [SOLVED] Is squeeze compatible with WD20EARS and other 2TB drives?
Stefan Monnier: I don't care much about performance: I have a WD10EADS in a wl700ge, for example (yes, that's a home router with a 266MHz MIPS cpu and 64MB of RAM: no fan, no noise). My two WD10EARS are sitting in a MiniITX case with four hotswap bays. The system runs 24/7, uses an Atom CPU (D510) and all filesystems on the WDs are encrypted (LUKS on top of LVM on top of software RAID10). Result: - I don't care about hard disk performance, since the CPU is the bottleneck for most IO operations. And my usage (audio/video streaming, fileserver for one or two clients) doesn't demand much performance anyway. - I do care about power usage and the CPU actually demands less power than all hard disks (4*3.5, 1*2.5 + slimline DVD) combined. - I only care a little about noise. Inside this case, the drives need active cooling anyway. Otherwise they would be running at 60°C. What I want to say is: everybody has different needs and general statements about the usefulness of specific drives are most probably false in one or another usage scenario. Regarding the 4k blocks: IMVHO, this time it's the free software crowd that didn't get their act together in time. These disks exist for quite a while now and even if some of them report the wrong block size, the tools don't even automatically do the right thing for disks that don't. J. -- I hate myself but have no clear idea why. [Agree] [Disagree] http://www.slowlydownward.com/NODATA/data_enter2.html signature.asc Description: Digital signature
Re: [SOLVED] Is squeeze compatible with WD20EARS and other 2TB drives?
Stefan Monnier put forth on 1/11/2011 9:46 PM: I have no idea what makes you so angry against green drives. I am against using any drive, at this time, in Linux, with a native sector size other than 512 bytes. Again, I fail to see why you're so emotional about it. You've got that backwards. You own a bunch of these drives and feel I am somehow attacking you personally when I say to stay away from the Green drives. If hard drives made me emotional, believe me, I'd have put a bullet in my head long ago. :) I think we should end this thread with this, which sums up the situation clearly, from a higher level perspective, for any Linux users planning on buying one of these WDC Green drives (maybe any of their drives): http://wdc.custhelp.com/cgi-bin/wdc.cfg/php/enduser/std_adp.php?p_faqid=5357 From the above page, with MUST READ in bold red type, at the top and bottom of the page: MUST READ: Western Digital is unable to provide support for the Unix/Linux operating systems outside of jumper configurations (for EIDE hard drives) and physical installation support. I'd not seen that before. They don't care for our business at all, apparently. Note the word unable. That's false. What they mean is unwilling. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d2dd6b8.2040...@hardwarefreak.com
Re: [SOLVED] Is squeeze compatible with WD20EARS and other 2TB drives?
On 11/01/11 01:26, Stan Hoeppner wrote: Stefan Monnier put forth on 1/9/2011 10:42 PM: I have no idea what makes you so angry against green drives. I am against using any drive, at this time, in Linux, with a native sector size other than 512 bytes. The Linux partitioning tools still do not easily/properly handle these hybrid drives with 4096 byte per sectors that translate 512 byte sectors to the host. Simply partitioning them correctly requires Ph.D. The average, and even some advanced, users cannot configure them for correct performance. ... In my experience with these drives, aligning to 4k sectors has always fixed any performance issues, and was achieved by creating partitions within fdisk invoked as follows: fdisk -cu -H224 -S56 /dev/sdx Greg -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d2cf98d.9070...@maths.otago.ac.nz
Re: [SOLVED] Is squeeze compatible with WD20EARS and other 2TB drives?
I have no idea what makes you so angry against green drives. I am against using any drive, at this time, in Linux, with a native sector size other than 512 bytes. Again, I fail to see why you're so emotional about it. I understand you don't recommend people buy such drives unless they know what they're doing, because their performance is sensitive to irrelevant details and is not great in any case (except maybe for streaming where the bandwidth is perfectly good, tho). That's OK: these drives aren't sold as speed daemons. The Linux partitioning tools still do not easily/properly handle these hybrid drives with 4096 byte per sectors that translate 512 byte sectors to the host. Indeed, although it would be very easy to make them do a better job. B. Doesn't care about performance of any kind, and is happy with sub 20MB/s rates. I don't care much about performance: I have a WD10EADS in a wl700ge, for example (yes, that's a home router with a 266MHz MIPS cpu and 64MB of RAM: no fan, no noise). But I also use another WD10EADS in my desktop, where it is faster (not by a large amount, but I did notice it, even tho I'm rather insensitive to such issues) than the barracuda it replaced. Admittedly, these WD10EADS don't use the 4KB blocks, so their performance is more in line with the usual. I'm down on these drives due to the maniacal 8 second head park interval, which likely does more mechanical damage than it saves power in dollar terms. There is simply no concrete evidence to back this urban legend. Think about it: this head-park speed is not a marketing argument, which means it is both technically and commercially trivial for WD to make the interval longer, so would WD really be so dumb as to keep the interval short just to screw their customers? And same for all the laptop drive manufacturers? I'm down on the fact that people buy them to save power, when they really don't save that much power compared to other drives. Not enough to notice on an electric bill. Doesn't hurt anyone, does it? The sector alignment issue bugs me the most. Second on the list is that these WD Green drives were designed to NOT be used, rather than used. The only way to get significant power savings is to sleep the drive most of the 24 hour day. BUT, all the other drives same almost as much power in their sleep modes. Yes, those drives are mostly meant for use cases where they're not spinning 24/7 (e.g. home server to store your videos, music, photos, backups, ...). And yes, most other 3½ drives consume a comparable amount of power when idle, but most non-green 3½ drives can't be spun down aggressively enough without wearing out much too quickly. So again, where's the advantage? Some of the drives are quieter by 3-4 dB. If your chassis sits on the floor you won't notice much difference. My desktop tower sits on the floor. And yes, I and the rest of my family noticed the difference, despite the CPU fan and system fan staying unchanged. If you have moderately loud system/CPU fans they'll drown out the noise generated by the drives. Hmm... how 'bout: If you have a fanless silent system, even these quiet green drives drown out the noise generated by the rest of the system. There's just nothing to really like about these drives, and many things to dislike. It's that simple. I love them: they're exactly what I need. Stefan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jwvoc7myfca.fsf-monnier+gmane.linux.debian.u...@gnu.org
Re: [SOLVED] Is squeeze compatible with WD20EARS and other 2TB drives?
Stefan Monnier put forth on 1/9/2011 10:42 PM: I have no idea what makes you so angry against green drives. I am against using any drive, at this time, in Linux, with a native sector size other than 512 bytes. The Linux partitioning tools still do not easily/properly handle these hybrid drives with 4096 byte per sectors that translate 512 byte sectors to the host. Simply partitioning them correctly requires Ph.D. The average, and even some advanced, users cannot configure them for correct performance. Thus, most end up with a drive that has native crappy performance, and then it's made even crappier because of the lack of proper partitioning support. Put 6 of these drives in RAID 5 with the misalignment and performance really sucks. I'm down on these drives because of the dozens upon dozens of posts I've seen on this list, linux-ide, linux-raid, etc, with owners of such drives banging their heads against the wall trying to get the partitions aligned properly. Anyone who buys one either A. Is a masochist B. Doesn't care about performance of any kind, and is happy with sub 20MB/s rates. I'm down on these drives due to the maniacal 8 second head park interval, which likely does more mechanical damage than it saves power in dollar terms. I'm down on the fact that people buy them to save power, when they really don't save that much power compared to other drives. Not enough to notice on an electric bill. The sector alignment issue bugs me the most. Second on the list is that these WD Green drives were designed to NOT be used, rather than used. The only way to get significant power savings is to sleep the drive most of the 24 hour day. BUT, all the other drives same almost as much power in their sleep modes. So again, where's the advantage? Some of the drives are quieter by 3-4 dB. If your chassis sits on the floor you won't notice much difference. If you have moderately loud system/CPU fans they'll drown out the noise generated by the drives. There's just nothing to really like about these drives, and many things to dislike. It's that simple. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d2afae0.6060...@hardwarefreak.com
Re: [SOLVED] Is squeeze compatible with WD20EARS and other 2TB drives?
On Sun, Jan 9, 2011 at 16:02, Stan Hoeppner s...@hardwarefreak.com wrote: Dotan Cohen put forth on 1/9/2011 5:58 AM: Thanks, Klistvud. I just purchased a WD10EARS (1 TB drive) and I noticed that my writes are _slow_. I think that it may be a KDE issue, there even is an open KDE bug that copy/paste is vry slow. But even copying via cp I feel that it's not moving, I need to benchmark the drive. Your post gives me some other things to check and configure. Thank you! Given the inherent performance problems Linux currently has with the 512/4096 byte sector hybrid drives, called Advanced Format by Western Digital, my recommendation to Linux users is to stay away from these drives at all costs, regardless of how attractive the price/GB ratio is. Specifically regarding the WDxxEARS drives, WD has a drive of the same capacity but with native 512 byte sectors in either or both of the Blue and Black product lines. The only advantage of the Green (EARS) line is a 3TB drive model not present in the Blue/Black lines. Additionally, the Blue and Black drives have full 7.2k spindles and will thus yield far superior performance to the Green (EARS) drives for the same size drive. If one is so power consumption conscious to be suckered into a Green (EARS) drive, then one needs to realize the CPU dissipates about 10 times the wattage/heat of a hard drive. Thus, concentrate your power saving efforts elsewhere than the disk drive. Buy a non green drive, and save yourself these sector alignment/performance headaches. Dotan, in your case, you should have purchased a WD10EALS instead of the WD10EARS: http://www.wdc.com/wdproducts/library/SpecSheet/ENG/2879-701277.pdf This Blue series 1TB drive has vastly superior performance and little additional power consumption compared to its WD10EARS cousin. http://www.newegg.com/Product/Product.aspx?Item=N82E16822136534cm_re=wd10eals-_-22-136-534-_-Product http://www.newegg.com/Product/Product.aspx?Item=N82E16822136490cm_re=WD10EARS-_-22-136-490-_-Product The Blue drive costs $5 USD more at Newegg. In all respects it is a vastly superior drive for Linux users over the WD10EARS Green drive--no sector alignment headaches, 50%+ better streaming and random IOPS performance. ...and unavailable in my market. I bought the EARS for the local equivalent of $76 USD, the next 1TB drive costs almost double that. Just to be sure, I checked the local price comparer website and sure enough I see the EALS for about $90 USD, however the store is out of stock. Actually, they haven't gotten stock yet! But I do feel suckered now that you mention it: I thought that this was a 7200 RPM drive. Oh well, what is done is done and I should have been more careful when I bought it. -- Dotan Cohen http://gibberish.co.il http://what-is-what.com -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimg15dgk-=h2lkuej67vwwfebwkpxy0fltc=...@mail.gmail.com
Re: [SOLVED] Is squeeze compatible with WD20EARS and other 2TB drives?
On Sun, Jan 9, 2011 at 17:08, Klistvud quotati...@aliceadsl.fr wrote: Glad to be of help. Please do read Stan Hoeppner's suggestion in this thread on using the dd command as a more reliable benchmark! The results are interesting: This is the WD10EARS drive, with both /home and / mounted on it in separate partitions: ✈ganymede:~$ dd if=/dev/zero of=/home/dotancohen/test.t count=10 bs=8192 10+0 records in 10+0 records out 81920 bytes (819 MB) copied, 7.96557 s, 103 MB/s This is an older 160 GB IDE Western Digital drive, that felt faster when both /home and / were on it (also in separate partitions), but now the whole drive is /home/music: ✈ganymede:~$ dd if=/dev/zero of=/home/music/test.t count=10 bs=8192 10+0 records in 10+0 records out 81920 bytes (819 MB) copied, 12.1413 s, 67.5 MB/s This is an older 400 GB IDE Western Digital drive that felt no different than the 160 GB unit, that now serves as a backup drive despite it actually being in the same case (I move backups offsite once a month): ✈ganymede:~$ dd if=/dev/zero of=/home/backup/test.t count=10 bs=8192 10+0 records in 10+0 records out 81920 bytes (819 MB) copied, 13.8581 s, 59.1 MB/s ✈ganymede:~$ So despite the feel of the drive, the green SATA drive blows the two snappier IDE drives out of the water. I wonder why this is, obviously the bottleneck is not the hard drive. I'll run memtest tonight, we'll see where that goes. Anyway, I hope I haven't hijacked, but this thread sure was interesting! -- Dotan Cohen http://gibberish.co.il http://what-is-what.com -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=rhxmzcyaznpaynfutm-fdk2biegjuk7g5d...@mail.gmail.com
Re: [SOLVED] Is squeeze compatible with WD20EARS and other 2TB drives?
Dotan Cohen: So despite the feel of the drive, the green SATA drive blows the two snappier IDE drives out of the water. Remember you only tested near sequential access. That's what hard disks are still quite good at. What makes your system feel sluggish is random access and WD's 5400rpm WD10EARS is most probably slower at that than most old 7200rpm drives. I wonder why this is, obviously the bottleneck is not the hard drive. Don't conclude too early. J. -- Thy lyrics in pop songs seem to describe my life uncannily accurately. [Agree] [Disagree] http://www.slowlydownward.com/NODATA/data_enter2.html signature.asc Description: Digital signature
Re: [SOLVED] Is squeeze compatible with WD20EARS and other 2TB drives?
On Sunday 19 December 2010 22:42:17 Eduard Bloch wrote: ignored the rest of the posting, ENOTIME to read all of the voodoo At least he wrote in comprehensible English. Lisi -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101091137.28723.lisi.re...@gmail.com
Re: [SOLVED] Is squeeze compatible with WD20EARS and other 2TB drives?
On Sat, Dec 18, 2010 at 23:32, Klistvud quotati...@aliceadsl.fr wrote: Attention: long post ahead! I don't use line wrapping because it breaks long URLs. If that makes you or your e-mail client cringe, you may as well read this at http://bufferoverflow.tiddlywiki.com instead (same text, nicer formatting). First of all, let me thank all of you who responded. As promised, I am giving feedback to the list so that future purchasers of Western Digital WD EARS/EADS models and similar Advanced Format hard drives may benefit. The first thing of notice is that the Load_Cycle_Count of the drive heads increases every 8 seconds by default. As seen on the Internet, this may pose a problem in the long run, since these drives are guaranteed to sustain a limited number of such head parking cycles. The number given varies from 300.000 to 1.000.000, depending on where you look. The first thing I did was, therefore, launch a shell script that wrote something to the drive every second. Not being content with this dirty workaround, I proceeded to download the WD proprietary utility wdidle3.exe, and the first link obtained by googling for wdidle3.exe did the trick: http://support.wdc.com/product/download.asp?groupid=609sid=113 I then proceeded to download a freedos bootable floppy image and copied it to a floppy disk using dd. Once the bootable floppy was thus created, I copied wdidle3.exe thereto. Reboot computer, change BIOS boot order to floppy first, saveexit, the floppy boots and I run wdidle3.exe. The utility offers three command-line switches, for viewing the current status of the Load_Cycle_Count parameter, for changing it, and for disabling it. No drive is specified, so if you change/disable the parameter, you are doing this to ALL and ANY WD drives in your system. I chose to disable head parking, and since I also have an older 160GB WD IDE disk in the box, the utility disabled head parking cycles for BOTH drives. Except that ... there be problems. As opposed to the old 160 GB drive, the setting didn't work for the new 2 TB drive. Instead, the frequency of the load cycles increased 16-fold, to a whopping 7200 cycles per hour! This quickly increased my Load_Cycle_Count parameter (checked by issuing smartctl --all /dev/sda) by several thousand ticks overnight. Interestingly enough, the drive loaded and unloaded its heads at the amazing rate of twice per second even while sustained copying was underway (copying a 10 GB directory subtree from one drive to another). I didn't notice the increased cycle count until the next morning, however. When I did, I rebooted the machine with the freedos floppy again and set the interval from disabled to every 300 seconds, which appears to be the maximum interval allowed. It would seem that, for the time being at least, this made the Load_Cycle_Count stay put at 22413. Whew! So, setting this bugger straight is probably the first thing you'll want to do after getting one of these WD drives. Now, the second issue: the hardware/logical sector alignment. Since it will affects real-world transfer speeds, let's first check out the theoretical speeds of this drive in this particular environment -- a 3GHz Pentium-IV motherboard with a humble integrated SATA controller (I think it's an early SATA-I generation). Before partitioning and formatting: obelix# hdparm -tT /dev/sda /dev/sda: Timing cached reads: 1726 MB in 2.00 seconds = 713.98 - 862.86 MB/sec (several iterations performed) Timing buffered disk reads: 336 MB in 3.01 seconds = 100.01 - 111.72 MB/sec (several iterations performed) After partitioning the drive, aligned on modulo 8 sector boundaries: obelix:# hdparm -tT /dev/sda /dev/sda: Timing cached reads: 1264 MB in 2.00 seconds = 631.97 MB/sec Timing buffered disk reads: 252 MB in 3.08 seconds = 81.80 MB/sec Hmm, while we're at it, why don't we also check the antiquated 160 GB drive on the obsolete IDE interface? obelix# hdparm -tT /dev/hda /dev/hda: Timing cached reads: 1348 MB in 2.00 seconds = 674.14 MB/sec Timing buffered disk reads: 206 MB in 3.02 seconds = 68.26 MB/sec Well, so much for the alleged superiority of serial ATA over IDE... Anyway. I have to prepend here that, Squeeze still not having reached stable, all of the following was performed on a stock Lenny i386 system (the reason being I have no Squeeze system yet). So, many of the following points may become obsolete in a matter of weeks when Squeeze, with a newer kernel and updated partitioning tools, reaches stable. The first thing is, fdisk in Lenny doesn't support GPT partitioning, so I had to use parted. I first used its Gnome variant, GParted, and must say that it cant't align the partitions. Even if you align the first sector by hand (in parted, since GParted can't do it) and de-select the Round to cylinders option in GParted as recommended in
Re: [SOLVED] Is squeeze compatible with WD20EARS and other 2TB drives?
Dotan Cohen put forth on 1/9/2011 5:58 AM: Thanks, Klistvud. I just purchased a WD10EARS (1 TB drive) and I noticed that my writes are _slow_. I think that it may be a KDE issue, there even is an open KDE bug that copy/paste is vry slow. But even copying via cp I feel that it's not moving, I need to benchmark the drive. Your post gives me some other things to check and configure. Thank you! Given the inherent performance problems Linux currently has with the 512/4096 byte sector hybrid drives, called Advanced Format by Western Digital, my recommendation to Linux users is to stay away from these drives at all costs, regardless of how attractive the price/GB ratio is. Specifically regarding the WDxxEARS drives, WD has a drive of the same capacity but with native 512 byte sectors in either or both of the Blue and Black product lines. The only advantage of the Green (EARS) line is a 3TB drive model not present in the Blue/Black lines. Additionally, the Blue and Black drives have full 7.2k spindles and will thus yield far superior performance to the Green (EARS) drives for the same size drive. If one is so power consumption conscious to be suckered into a Green (EARS) drive, then one needs to realize the CPU dissipates about 10 times the wattage/heat of a hard drive. Thus, concentrate your power saving efforts elsewhere than the disk drive. Buy a non green drive, and save yourself these sector alignment/performance headaches. Dotan, in your case, you should have purchased a WD10EALS instead of the WD10EARS: http://www.wdc.com/wdproducts/library/SpecSheet/ENG/2879-701277.pdf This Blue series 1TB drive has vastly superior performance and little additional power consumption compared to its WD10EARS cousin. http://www.newegg.com/Product/Product.aspx?Item=N82E16822136534cm_re=wd10eals-_-22-136-534-_-Product http://www.newegg.com/Product/Product.aspx?Item=N82E16822136490cm_re=WD10EARS-_-22-136-490-_-Product The Blue drive costs $5 USD more at Newegg. In all respects it is a vastly superior drive for Linux users over the WD10EARS Green drive--no sector alignment headaches, 50%+ better streaming and random IOPS performance. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d29bfdd.4040...@hardwarefreak.com
Re: [SOLVED] Is squeeze compatible with WD20EARS and other 2TB drives?
Dne, 09. 01. 2011 12:58:22 je Dotan Cohen napisal(a): Thanks, Klistvud. I just purchased a WD10EARS (1 TB drive) and I noticed that my writes are _slow_. I think that it may be a KDE issue, there even is an open KDE bug that copy/paste is vry slow. But even copying via cp I feel that it's not moving, I need to benchmark the drive. Your post gives me some other things to check and configure. Thank you! Glad to be of help. Please do read Stan Hoeppner's suggestion in this thread on using the dd command as a more reliable benchmark! -- Cheerio, Klistvud http://bufferoverflow.tiddlyspot.com Certifiable Loonix User #481801 Please reply to the list, not to me. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1294585698.387...@compax
Re: [SOLVED] Is squeeze compatible with WD20EARS and other 2TB drives?
Klistvud: Before partitioning and formatting: obelix# hdparm -tT /dev/sda … After partitioning the drive, aligned on modulo 8 sector boundaries: obelix:# hdparm -tT /dev/sda Your test is unsuitable to detect any alignment-related performance issues. J. -- No-one appears to be able to help me. [Agree] [Disagree] http://www.slowlydownward.com/NODATA/data_enter2.html signature.asc Description: Digital signature
Re: [SOLVED] Is squeeze compatible with WD20EARS and other 2TB drives?
Dne, 09. 01. 2011 17:35:07 je Jochen Schulz napisal(a): Klistvud: Before partitioning and formatting: obelix# hdparm -tT /dev/sda … After partitioning the drive, aligned on modulo 8 sector boundaries: obelix:# hdparm -tT /dev/sda Your test is unsuitable to detect any alignment-related performance issues. J. -- No-one appears to be able to help me. [Agree] [Disagree] http://www.slowlydownward.com/NODATA/data_enter2.html Care to elaborate why? I guess many people will be purchasing these hard drives in the near future, so any input is welcome. -- Cheerio, Klistvud http://bufferoverflow.tiddlyspot.com Certifiable Loonix User #481801 Please reply to the list, not to me. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1294595514.387...@compax
Re: [SOLVED] Is squeeze compatible with WD20EARS and other 2TB drives?
If one is so power consumption conscious to be suckered into a Green (EARS) drive, then one needs to realize the CPU dissipates about 10 times the wattage/heat of a hard drive. Thus, concentrate your power I have no idea what makes you so angry against green drives. But I can assure you there are very good reasons to use them: - lower power consumption (and no: not all CPUs use 10x more power. Think of home-routers or atom-based systems). - less heat (so you can put more drives in the same machine, or push your CPU a bit more, or turn down your fans). - less noise (the main motivation for me). - survive more sleep cycles, so you can let them spin down just like laptop drives (after all, they are pretty much like laptop drives, except larger capacity and cheaper). Maybe none of those things matter to your situation, of course, but heat is the big issue for many computer systems, so it's not nearly as rare as you may think. Stefan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jwvwrmdz88p.fsf-monnier+gmane.linux.debian.u...@gnu.org
Re: [SOLVED] Is squeeze compatible with WD20EARS and other 2TB drives?
The first thing of notice is that the Load_Cycle_Count of the drive heads increases every 8 seconds by default. As seen on the Internet, this may pose a problem in the long run, since these drives are guaranteed to sustain a limited number of such head parking cycles. The number given varies from 300.000 to 1.000.000, depending on where you look. Those two numbers have nothing to do with each other. The 30 limit applies to spin-down (aka Start_Stop_Count), not to head-park (aka Load_Cycle_Count). Stefan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jwvr5clz7x7.fsf-monnier+gmane.linux.debian.u...@gnu.org
Re: [SOLVED] Is squeeze compatible with WD20EARS and other 2TB drives?
Klistvud: Dne, 09. 01. 2011 17:35:07 je Jochen Schulz napisal(a): Klistvud: After partitioning the drive, aligned on modulo 8 sector boundaries: obelix:# hdparm -tT /dev/sda Your test is unsuitable to detect any alignment-related performance issues. Care to elaborate why? Because that's streaming big chunks from the disk and that doesn't trigger any alignment issues. The problem about alignment is that accessing a single, unaligned filesystem block makes it necessary for the disk to read two blocks instead of one. As I understand it, this issue mostly impacts random access performance. I don't know of any reliable way to test this, but you need to test a filesystem, not a raw disk device. J. -- Television advertisements are the apothesis of twentieth century culture. [Agree] [Disagree] http://www.slowlydownward.com/NODATA/data_enter2.html signature.asc Description: Digital signature
Re: [SOLVED] Is squeeze compatible with WD20EARS and other 2TB drives?
Dne, 19. 12. 2010 05:31:37 je Stan Hoeppner napisal(a): What is the result of? dd if=/dev/zero of=/some/filesystem/test count=10 bs=8192 That will write an 810MB file of all zeros, and will give you a much better idea of the raw streaming write performance vs copying files from the old 160GB drive to the new one. I would think the result should be a bit higher than 60MB/s. Also, make sure you're using the deadline elevator instead of CFQ as it yields better performance, especially on SATA systems that don't support NCQ: $ echo deadline /sys/block/sda/queue/scheduler You may want to add this to your boot scripts to make it permanent. I roll this option as the default in my custom kernels. Thanks for the suggestion, Stan. Using dd I get a much higher figure, namely around 83 MB/s. Changing the elevator doesn't make a difference on my system though. -- Cheerio, Klistvud http://bufferoverflow.tiddlyspot.com Certifiable Loonix User #481801 Please reply to the list, not to me. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1292749820.598...@compax
Re: [SOLVED] Is squeeze compatible with WD20EARS and other 2TB drives?
Klistvud put forth on 12/19/2010 3:10 AM: Dne, 19. 12. 2010 05:31:37 je Stan Hoeppner napisal(a): What is the result of? dd if=/dev/zero of=/some/filesystem/test count=10 bs=8192 That will write an 810MB file of all zeros, and will give you a much better idea of the raw streaming write performance vs copying files from the old 160GB drive to the new one. I would think the result should be a bit higher than 60MB/s. Also, make sure you're using the deadline elevator instead of CFQ as it yields better performance, especially on SATA systems that don't support NCQ: $ echo deadline /sys/block/sda/queue/scheduler You may want to add this to your boot scripts to make it permanent. I roll this option as the default in my custom kernels. Thanks for the suggestion, Stan. Using dd I get a much higher figure, namely around 83 MB/s. Changing the elevator doesn't make a difference on my system though. 83 MB/s isn't too bad for that drive. IIRC the WD20EARS is a 5400 RPM drive with variable spindle speed to reduce power consumption. My 7200 RPM WD Blue 500GB WD5000AAKS single platter drive hits about the same dd sequential write speed, using lower bit density but higher spindle speed: /$ dd if=/dev/zero of=./test count=10 bs=8192 10+0 records in 10+0 records out 81920 bytes (819 MB) copied, 9.8092 s, 83.5 MB/s The deadline elevator may not help much with streaming reads/writes. It does help a bit with random read/writes, especially under multi-user or multi-threading random seek disk workloads. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d0ddd7d.70...@hardwarefreak.com
Re: [SOLVED] Is squeeze compatible with WD20EARS and other 2TB drives?
On Sat, 18 Dec 2010 22:32:10 +0100 Klistvud quotati...@aliceadsl.fr wrote: Attention: long post ahead! I don't use line wrapping because it breaks long URLs. If that makes you or your e-mail client cringe, you may as well read this at http://bufferoverflow.tiddlywiki.com instead (same text, nicer formatting). *Somethings's* doing line-wrapping for you - your message contains plenty of newlines (hex 0A). And I'm not sure what you mean by line-wrapping breaking long urls. A proper line-wrapper understands urls, and won't break them (although my beloved Sylph admittedly uses a broken line-wrapper :( : http://www.sraoss.jp/pipermail/sylpheed/2010-September/004166.html Of course, some badly broken (e.g., Microsoft) MUAs will break urls while displaying them for the recipient ... Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101219165214.f1bc39f4.cele...@gmail.com
Re: [SOLVED] Is squeeze compatible with WD20EARS and other 2TB drives?
#include hallo.h * Klistvud [Sat, Dec 18 2010, 10:32:10PM]: First of all, let me thank all of you who responded. As promised, I am giving feedback to the list so that future purchasers of Western Digital WD EARS/EADS models and similar Advanced Format hard drives may benefit. Err, what? EADS don't use AF, TTBOMK. The first thing of notice is that the Load_Cycle_Count of the drive heads increases every 8 seconds by default. As seen on the Internet, That only refers to EARS. And it's wrong. Umount everything on that disk and wait a while, no loading/unloading should stop. What really happens is that the disk parks after 8 seconds when it's IDLE. Which is ok when you either read or write stuff all the time or don't do anything at all. It is not ok if you use them as system disks where a few bytes are written every couple of seconds and certain popular Linux filesystems like to flush (means: write out to disk) that data every 10..15 seconds (just a bit more than 8 seconds) and so causing the LCC growing quite quickly over time. So DO NOT use an EARS drive as SYSTEM DISK. this may pose a problem in the long run, since these drives are guaranteed to sustain a limited number of such head parking cycles. The number given varies from 300.000 to 1.000.000, depending on where you look. The first thing I did was, therefore, launch a There is no reason to put the word guaranteed into double-quotes or refer to weird sites. Just have a look at the official data sheet and the common definition of MTBF please. the WD proprietary utility wdidle3.exe, and the first link obtained by googling for wdidle3.exe did the trick: http://support.wdc.com/product/download.asp?groupid=609sid=113 ... thousand ticks overnight. Interestingly enough, the drive loaded and unloaded its heads at the amazing rate of twice per second even ... disabled to every 300 seconds, which appears to be the maximum interval allowed. It would seem that, for the time being at least, this made the Load_Cycle_Count stay put at 22413. Whew! Err, what? You play with a dangerous toy which was not designed for your drive and you wonder that it's all messed up now? Now, the second issue: the hardware/logical sector alignment. Since it will affects real-world transfer speeds, let's first check out the theoretical speeds of this drive in this particular environment -- a 3GHz Pentium-IV motherboard with a humble integrated SATA controller (I think it's an early SATA-I generation). My company had a lot of them. The SATA controllers were crap performance-wise. I remember a colleague who got a shiny new OCZ SSD drive which was supposed to deliver 200MB/s but never got beyond 70MB/s on his system. The solution was a 15EUR PCIe controller card which suddenly make it work as expected. obelix# hdparm -tT /dev/sda Err, what does this have to do with pro/contra of logical sector sizes? Counter-example, WD20EARS on an AMD-78xx mainboard: /dev/sdc: Timing cached reads: 8042 MB in 2.00 seconds = 4023.46 MB/sec Timing buffered disk reads: 360 MB in 3.02 seconds = 119.38 MB/sec ignored the rest of the posting, ENOTIME to read all of the voodoo Eduard. -- Naja, Garbage Collector eben. Holt den Müll sogar vom Himmel. (Heise Trollforum über Java in der Flugzeugsteuerung) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101219224217.ga5...@rotes76.wohnheim.uni-kl.de
[SOLVED] Is squeeze compatible with WD20EARS and other 2TB drives?
Attention: long post ahead! I don't use line wrapping because it breaks long URLs. If that makes you or your e-mail client cringe, you may as well read this at http://bufferoverflow.tiddlywiki.com instead (same text, nicer formatting). First of all, let me thank all of you who responded. As promised, I am giving feedback to the list so that future purchasers of Western Digital WD EARS/EADS models and similar Advanced Format hard drives may benefit. The first thing of notice is that the Load_Cycle_Count of the drive heads increases every 8 seconds by default. As seen on the Internet, this may pose a problem in the long run, since these drives are guaranteed to sustain a limited number of such head parking cycles. The number given varies from 300.000 to 1.000.000, depending on where you look. The first thing I did was, therefore, launch a shell script that wrote something to the drive every second. Not being content with this dirty workaround, I proceeded to download the WD proprietary utility wdidle3.exe, and the first link obtained by googling for wdidle3.exe did the trick: http://support.wdc.com/product/download.asp?groupid=609sid=113 I then proceeded to download a freedos bootable floppy image and copied it to a floppy disk using dd. Once the bootable floppy was thus created, I copied wdidle3.exe thereto. Reboot computer, change BIOS boot order to floppy first, saveexit, the floppy boots and I run wdidle3.exe. The utility offers three command-line switches, for viewing the current status of the Load_Cycle_Count parameter, for changing it, and for disabling it. No drive is specified, so if you change/disable the parameter, you are doing this to ALL and ANY WD drives in your system. I chose to disable head parking, and since I also have an older 160GB WD IDE disk in the box, the utility disabled head parking cycles for BOTH drives. Except that ... there be problems. As opposed to the old 160 GB drive, the setting didn't work for the new 2 TB drive. Instead, the frequency of the load cycles increased 16-fold, to a whopping 7200 cycles per hour! This quickly increased my Load_Cycle_Count parameter (checked by issuing smartctl --all /dev/sda) by several thousand ticks overnight. Interestingly enough, the drive loaded and unloaded its heads at the amazing rate of twice per second even while sustained copying was underway (copying a 10 GB directory subtree from one drive to another). I didn't notice the increased cycle count until the next morning, however. When I did, I rebooted the machine with the freedos floppy again and set the interval from disabled to every 300 seconds, which appears to be the maximum interval allowed. It would seem that, for the time being at least, this made the Load_Cycle_Count stay put at 22413. Whew! So, setting this bugger straight is probably the first thing you'll want to do after getting one of these WD drives. Now, the second issue: the hardware/logical sector alignment. Since it will affects real-world transfer speeds, let's first check out the theoretical speeds of this drive in this particular environment -- a 3GHz Pentium-IV motherboard with a humble integrated SATA controller (I think it's an early SATA-I generation). Before partitioning and formatting: obelix# hdparm -tT /dev/sda /dev/sda: Timing cached reads: 1726 MB in 2.00 seconds = 713.98 - 862.86 MB/sec (several iterations performed) Timing buffered disk reads: 336 MB in 3.01 seconds = 100.01 - 111.72 MB/sec (several iterations performed) After partitioning the drive, aligned on modulo 8 sector boundaries: obelix:# hdparm -tT /dev/sda /dev/sda: Timing cached reads: 1264 MB in 2.00 seconds = 631.97 MB/sec Timing buffered disk reads: 252 MB in 3.08 seconds = 81.80 MB/sec Hmm, while we're at it, why don't we also check the antiquated 160 GB drive on the obsolete IDE interface? obelix# hdparm -tT /dev/hda /dev/hda: Timing cached reads: 1348 MB in 2.00 seconds = 674.14 MB/sec Timing buffered disk reads: 206 MB in 3.02 seconds = 68.26 MB/sec Well, so much for the alleged superiority of serial ATA over IDE... Anyway. I have to prepend here that, Squeeze still not having reached stable, all of the following was performed on a stock Lenny i386 system (the reason being I have no Squeeze system yet). So, many of the following points may become obsolete in a matter of weeks when Squeeze, with a newer kernel and updated partitioning tools, reaches stable. The first thing is, fdisk in Lenny doesn't support GPT partitioning, so I had to use parted. I first used its Gnome variant, GParted, and must say that it cant't align the partitions. Even if you align the first sector by hand (in parted, since GParted can't do it) and de-select the Round to cylinders option in GParted as recommended in http://www.ibm.com/developerworks/linux/library/l-4kb-sector-disks/index.html (which was my
Re: [SOLVED] Is squeeze compatible with WD20EARS and other 2TB drives?
Klistvud put forth on 12/18/2010 3:32 PM: Before partitioning and formatting: obelix# hdparm -tT /dev/sda /dev/sda: Timing cached reads: 1726 MB in 2.00 seconds = 713.98 - 862.86 MB/sec (several iterations performed) Timing buffered disk reads: 336 MB in 3.01 seconds = 100.01 - 111.72 MB/sec (several iterations performed) After partitioning the drive, aligned on modulo 8 sector boundaries: obelix:# hdparm -tT /dev/sda /dev/sda: Timing cached reads: 1264 MB in 2.00 seconds = 631.97 MB/sec Timing buffered disk reads: 252 MB in 3.08 seconds = 81.80 MB/sec expected, the rsync results for the last partition became consistent with the other partitions (i.e. around 60 MB/s). All testing was done with a ~700-MB ISO file What is the result of? dd if=/dev/zero of=/some/filesystem/test count=10 bs=8192 That will write an 810MB file of all zeros, and will give you a much better idea of the raw streaming write performance vs copying files from the old 160GB drive to the new one. I would think the result should be a bit higher than 60MB/s. Also, make sure you're using the deadline elevator instead of CFQ as it yields better performance, especially on SATA systems that don't support NCQ: $ echo deadline /sys/block/sda/queue/scheduler You may want to add this to your boot scripts to make it permanent. I roll this option as the default in my custom kernels. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d0d8aa9.3050...@hardwarefreak.com
