![](https://seccdn.libravatar.org/avatar/a836ff90f492078f494adcf0c6059fc6.jpg?s=120&d=mm&r=g)
Greg Freemyer composed on 2015-03-16 09:32 (UTC-0400):
If the workload is small 1 page writes, then the penalty is huge. For every write a read/modify/write cycle has to be implemented.
Is it really? What kind of use case produces many writes of different small files in sequence or short order? About the only one I can think of is package management extracting from rpms config files, but there the configs would typically be interspersed among much larger binaries, loosing the impact of the penalty within a much larger overall operation.
You would need to benchmark your typical load, but if you do lots of small i/o's, I think you will find that 8.3 msecs a pretty major penalty.
This highlights why I brought up the subject of not having located benchmarking done by others in the earlier thread. Other than the brief mention by Chris of linux-raid, I've not noticed anyone mention exposure to or experience with such benchmarking. I'm not a strong believer in benchmarking always being fairly representative of real life operation either. I'm thinking that on older systems that are slower to start with, and having been using disks much slower than what evolution has since provided, that disks replaced would have been significantly slower than anything with 4k on the platters, with net post-upgrade performance results simply less improved by using newer without aligning, not slower than with the older. IOW, my suspicion is there would generally be little if any observable penalty in an upgrade context, compared to benchmarking using all recent hardware. I do have one 3.0GHz P4 HT testing machine with 2G RAM and only 64 bit installations that I wonder about. hdparm reports 74MB/sec. It rather routinely seems slower than Socket A systems running 2GHz or slower, and slower GHz 32 bit P4s without HT. It's legacy-partitioned HD was purchased for cheap used, manufactured by Seagate, but model HP432337004 GB0500C4413, firmware HPG1, manufactured September 2007. Maybe it's one of the earliest 512e devices out the door, claiming to have 512 byte sectors, as reported by hdparm --getpbsz and --getss, hdparm -I and parted -l,but in fact with 4k on the platters and emulation in disguise, being suboptimally handled by open source kernels and drivers on non-HP hardware? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org