Re: impact of unaligned partitions/slices on 4kB sector drives (wd10ears)
On Sat, May 14, 2011 at 9:14 PM, Kenneth R Westerback kwesterb...@rogers.com wrote: 1) Don't cross post. 2) Install something more recent that 4.6 (e.g. 4.9) and you will find that partitions and filesystems will be aligned on 4K boundaries. 3) If you can, without trying hard, end up with misaligned partitions on a fresh 4.9 install then please detail the steps you followed and I for one would be very interested. Perhaps not top-posting, and trimming excessive quoted material which is not actually relevant to the content you're adding, would help as well? That said 4096 byte block alignment is an ongoing issue in virtualization. If your storage on your virtualization server is 4096 byte block aligned, such as NetApp fibre channel or NFS images for high availability VMWare environments, Since the guests currently have no way to be aware of the back-end storage, and won't until virtualization technologies include options for 4096 byte block drive emulation, it's a problem. it's vital that the guest images have their partitions aligned. It's particularly criticla to avoid the 63-block DOS compatibility before the first partition. I've personally written and posted tools for that for Linux environments, but haven't tried it for OpenBSD: I'd welcome guidelines for that.
Re: impact of unaligned partitions/slices on 4kB sector drives (wd10ears)
List: openbsd-tech Subject:impact of unaligned partitions/slices on 4kB sector drives (wd10ears) From: Robert robert () openbsd ! pap ! st Date: 2010-01-06 22:54:34 Message-ID: 20100106235434.55963d32 () openbsd ! pap ! st Hello, i did some measurements on the impact that unaligned partitions/slices have on the new harddrives that use ondisk 4kB sectors and export them as 512B sectors. [1] My tests were done on a Western Digital WD10EARS. [2] CONCLUSION: Having unaligned partition/slices on those disks leads to noticable performance penalty under realworld workloads. IMPLICATIONS: 1. The rounding of unit sizes to cylinder boundaries by disklabel has to be evaluated. 2. A FAQ entry for the advanced format disks is needed to tell people to set the XP jumper. (more on that later) If disklabel is not modified, that entry would also have to explain the alignement implications and how to use a calculator. TEST RESULTS: - sequential write/read speeds --- dd bs | aligned | unaligned | wd10eads* | | | 4k write | 97433116 | 86349673 | 80762241 (bytes/sec) 64k w | 101273894 | 85616298 | 81234814 1m w | 98291974 | 79201231 | 83113302 | | | 4k read | 103706513 | 104434701 | 82723667 64k r | 105136468 | 104453140 | 85552816 1m r | 104228605 | 104921901 | 85650289 (* wd10eads is the previous generation to the wd10ears with 32mb cache and usual 512B ondisk sectors. Disk is in a different system! That system is not idle so actual numbers might be higher.) - extracting a source tree --- aligned : 6m26.31s unaligned : 14m30.30s - build kernel / make obj / make build --- | aligned | unaligned kernel | 2m27.94s | 2m48.12s make obj | 0m28.51s | 1m01.41s make build | 36m07.27s | 70m51.58s EXPLANAITIONS (or whatever :): Those numbers are kinda scary. I would not have expected such bad results for the builds from my earlier sequential rw tests i sent to misc@. (Just to make it clear, if the partition/slices are not aligned, the disk has to read every 4k sector it wants to write to, before it can actually do that. The 64MB of cache help to elevate that up to some point.) This drive has a XP legacy jumper. (Same as WD15EARS and WD20EARS.) It is intended to be used for Windows XP systems with a single partition over the whole drive. XP uses the same 63 sector offset as OpenBSD does. Setting this jumper, transparently alignes the 63 sectors infront of a 4k sector boundary. When that jumper is set, slices inside the partition only have to be multiples of 8 big. The issue is with disklables rounding down to the nearest cylinder boundary. This will mess up the nice multiplication by 1024, which would lead to a size divisable by 8. The rounding down is always done when using units, but not when requesting a size without a unit/in sectors. So slices can be aligned that way by hand. That rounding to cylinders is not needed, afaik. So without that, a simple rtfaq! set the damn jumper! would be enough, to get the best performance out of such harddisks. Below you can find more info about my test setup and the test outputs. Cheers, - Robert [1] http://www.wdc.com/advformat [2] http://www.wdc.com/en/products/products.asp?driveidv3 TESTS: aligned == XP jumper set unaligned == XP jumper NOT set* (* without the jumper, the partition/slices are off by one 512B sector.) I installed a snapshot i had on hand (see dmesg) and went from there. (Fresh installl without the jumper.) Source-tree used is -current from some hours ago. I sync'ed before every test. disk layout and ramdisk was the same in both scenarios. - dmesg --- OpenBSD 4.6-current (GENERIC.MP) #40: Tue Dec 29 01:02:20 MST 2009 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 3488088064 (3326MB) avail mem = 3388391424 (3231MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xf0730 (61 entries) bios0: vendor American Megatrends Inc. version 1104 date 09/11/2009 bios0: ASUSTeK Computer INC. P5QL-E acpi0 at bios0: rev 2 acpi0: tables DSDT FACP APIC MCFG OEMB HPET OSFR acpi0: wakeup devices P0P2(S4) P0P3(S4) P0P1(S4) UAR1(S4) PS2K(S4) PS2M(S4) EUSB(S4) \ USBE(S4) P0P5(S4) P0P6(S4) P0P7(S4) P0P8(S4) P0P9(S4) GBEC(S4) USB0(S4) USB1(S4) \ use rev 1.10/21.00 addr 2 uhidev1: iclass 3/1 ukbd0 at uhidev1: 8 modifier keys, 6 key codes wskbd1 at ukbd0 mux 1 wskbd1: connecting to wsdisplay0 vscsi0 at root scsibus4 at vscsi0: 256 targets softraid0 at root root on sd0a swap on sd0b dump on sd0b (( fwiw, jacob: that azalia is just disabled. the iic0 should be an asus ai booster. still have to modify the live driver for that soundblaster 5.1 vx. )) - fdisk --- Disk: sd0 geometry: 121601/255/63 [1953525168
Re: impact of unaligned partitions/slices on 4kB sector drives (wd10ears)
I'm starting to get angry about the _horrible_ performance on this drive (WD10EARS-00Y), some developer ever got a chance to see something about this? The default alignment was changed. Do a 'disklabel sd0', if / starts at sector 63 then it was created before this change was made, in which case you could dump your filesystems, reinstall, and restore them. As well as newer hard drives (AIUI *all* new drive models since the start of this year have larger sector sizes), CF and SSD are likely to benefit. - PatchSet 476 Date: 2010/07/27 01:49:42 Author: krw Branch: HEAD Tag: (none) Log: Align FFS filesystem start and end sectors so the start is on a bsize boundary and the end fills up the last bsize chunk. Don't change the start sector if it is the first sector of the OpenBSD portion of the disk. Don't attempt to align on SUN_CYLCHECK architectures. They are attempting a different alignment. This is an attempt to ensure that FFS i/o's are aligned for optimal performance on newer disks that lie about their sector size. Members: editor.c:1.240-1.241 -
Re: impact of unaligned partitions/slices on 4kB sector drives (wd10ears)
On Sat, May 14, 2011 at 03:43:23AM -0500, Abel Abraham Camarillo Ojeda wrote: (( If you read this far, have a cookie and wonder with me about that quick extraction... The system this drive is in has the same board, but everything else is slower and not idle when meassured...)) I'm starting to get angry about the _horrible_ performance on this drive (WD10EARS-00Y), some developer ever got a chance to see something about this? 4.8 and newer should install on the disk fine (when reinitialzing the disk), respecting 4k boundaries. Alas, if your disk has been installed using an older version, the boundaries probably won't align. Updating won't be enough because it keep the old mbr and disklabel. -Otto The original message is at: http://marc.info/?l=openbsd-techm=126281899324219w=2 (I wasn't subscribed to this list back then) Thanks. OpenBSD 4.9-current (kobj) #0: Sun May 1 14:32:33 CDT 2011 root@maetel.00z:/usr/kobj real mem = 1608056832 (1533MB) avail mem = 1551196160 (1479MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xfd400 (50 entries) bios0: vendor American Megatrends Inc. version V1.3 date 11/15/2010 bios0: MSI MS-7623 acpi0 at bios0: rev 0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC MCFG OEMB SRAT HPET SSDT acpi0: wakeup devices PCE2(S4) PCE3(S4) PCE4(S4) PCE5(S4) PCE6(S4) PCE7(S4) PCE9(S4) PCEA(S4) PCEB(S4) PCEC(S4) SBAZ(S4) PSKE(S4) PSMS(S4) ECIR(S4) PS2K(S3) PS2M(S3) P0PC(S4) UHC1(S4) UHC2(S4) UHC3(S4) USB4(S4) UHC5(S4) UHC6(S4) UHC7(S4) PWRB(S3) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Phenom(tm) II X4 955 Processor, 3200.77 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu0: apic clock running at 200MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Phenom(tm) II X4 955 Processor, 3200.16 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu1: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD Phenom(tm) II X4 955 Processor, 3200.15 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW cpu2: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu2: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu2: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD Phenom(tm) II X4 955 Processor, 3200.16 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW cpu3: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu3: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu3: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318180 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (P0P1) acpiprt2 at acpi0: bus -1 (PCE2) acpiprt3 at acpi0: bus -1 (PCE3) acpiprt4 at acpi0: bus -1 (PCE4) acpiprt5 at acpi0: bus 2 (PCE5) acpiprt6 at acpi0: bus -1 (PCE6) acpiprt7 at acpi0: bus -1 (PCE7) acpiprt8 at acpi0: bus -1 (PCE9) acpiprt9 at acpi0: bus -1 (PCEA) acpiprt10 at acpi0: bus -1 (PCEB) acpiprt11 at acpi0: bus -1 (PCEC) acpiprt12 at acpi0: bus 3 (P0PC) acpicpu0 at acpi0: PSS acpicpu1 at acpi0: PSS acpicpu2 at acpi0: PSS acpicpu3 at acpi0: PSS acpibtn0 at acpi0: PWRB pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 AMD RS780 Host rev 0x00 ppb0 at pci0 dev 1 function 0 AMD RS780 PCIE rev 0x00 pci1 at ppb0 bus 1 vga1 at pci1 dev 5 function 0 vendor ATI, unknown product 0x9616 rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) ppb1 at pci0 dev 5 function 0 AMD RS780 PCIE rev 0x00: apic 4 int 17 pci2 at ppb1 bus 2 alc0 at pci2 dev 0 function 0 Attansic Technology
Re: impact of unaligned partitions/slices on 4kB sector drives (wd10ears)
On 14/05/2011, at 6:43 PM, Abel Abraham Camarillo Ojeda wrote: I'm starting to get angry about the _horrible_ performance on this drive (WD10EARS-00Y), some developer ever got a chance to see something about this? don't get angry, it's just a disk. we changed the default alignment of partitions on all disks to mitigate this problem. the only issue you may have with a default install on one of these drives is a small fragment size on the ffs partitions. i have had a look at querying disks for their physical and logical block alignments and offsets, but the the WD??EARS-00? drives dont report this info. according to western digital, the next generation of these drives (WD??EARS-11? iirc) are supposed to report them. if i ever find a disk that does report the physical to logical alignment, i might have a look at having the system make use of those values. huggz, dlg The original message is at: http://marc.info/?l=openbsd-techm=126281899324219w=2 (I wasn't subscribed to this list back then) Thanks. OpenBSD 4.9-current (kobj) #0: Sun May 1 14:32:33 CDT 2011 root@maetel.00z:/usr/kobj real mem = 1608056832 (1533MB) avail mem = 1551196160 (1479MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xfd400 (50 entries) bios0: vendor American Megatrends Inc. version V1.3 date 11/15/2010 bios0: MSI MS-7623 acpi0 at bios0: rev 0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC MCFG OEMB SRAT HPET SSDT acpi0: wakeup devices PCE2(S4) PCE3(S4) PCE4(S4) PCE5(S4) PCE6(S4) PCE7(S4) PCE9(S4) PCEA(S4) PCEB(S4) PCEC(S4) SBAZ(S4) PSKE(S4) PSMS(S4) ECIR(S4) PS2K(S3) PS2M(S3) P0PC(S4) UHC1(S4) UHC2(S4) UHC3(S4) USB4(S4) UHC5(S4) UHC6(S4) UHC7(S4) PWRB(S3) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Phenom(tm) II X4 955 Processor, 3200.77 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DN OW cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu0: apic clock running at 200MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Phenom(tm) II X4 955 Processor, 3200.16 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DN OW cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu1: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD Phenom(tm) II X4 955 Processor, 3200.15 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DN OW cpu2: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu2: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu2: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD Phenom(tm) II X4 955 Processor, 3200.16 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DN OW cpu3: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu3: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu3: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318180 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (P0P1) acpiprt2 at acpi0: bus -1 (PCE2) acpiprt3 at acpi0: bus -1 (PCE3) acpiprt4 at acpi0: bus -1 (PCE4) acpiprt5 at acpi0: bus 2 (PCE5) acpiprt6 at acpi0: bus -1 (PCE6) acpiprt7 at acpi0: bus -1 (PCE7) acpiprt8 at acpi0: bus -1 (PCE9) acpiprt9 at acpi0: bus -1 (PCEA) acpiprt10 at acpi0: bus -1 (PCEB) acpiprt11 at acpi0: bus -1 (PCEC) acpiprt12 at acpi0: bus 3 (P0PC) acpicpu0 at acpi0: PSS acpicpu1 at acpi0: PSS acpicpu2 at acpi0: PSS acpicpu3 at acpi0: PSS acpibtn0 at acpi0: PWRB pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 AMD RS780 Host rev 0x00 ppb0 at pci0 dev 1 function 0 AMD RS780 PCIE rev 0x00 pci1 at ppb0 bus 1 vga1 at pci1 dev 5 function 0 vendor ATI, unknown product 0x9616 rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) ppb1 at
Re: impact of unaligned partitions/slices on 4kB sector drives (wd10ears)
On Sat, May 14, 2011 at 4:08 AM, David Gwynne l...@animata.net wrote: i have had a look at querying disks for their physical and logical block alignments and offsets, but the the WD??EARS-00? drives dont report this info. according to western digital, the next generation of these drives (WD??EARS-11? iirc) are supposed to report them. if i ever find a disk that does report the physical to logical alignment, i might have a look at having the system make use of those values. Yes, this is exactly the last thing I remember about this topic. huggz, dlg This isn't my boot disk, it's the storage disk, I'm going to re-disklabel, and newfs it; Do I also need to do something with fdisk? I'm not sure... Thanks.
Re: impact of unaligned partitions/slices on 4kB sector drives (wd10ears)
On Sat, May 14, 2011 at 4:22 AM, Otto Moerbeek o...@drijf.net wrote: On Sat, May 14, 2011 at 04:15:51AM -0500, Abel Abraham Camarillo Ojeda wrote: On Sat, May 14, 2011 at 4:08 AM, David Gwynne l...@animata.net wrote: i have had a look at querying disks for their physical and logical block alignments and offsets, but the the WD??EARS-00? drives dont report this info. according to western digital, the next generation of these drives (WD??EARS-11? iirc) are supposed to report them. if i ever find a disk that does report the physical to logical alignment, i might have a look at having the system make use of those values. Yes, this is exactly the last thing I remember about this topic. huggz, dlg This isn't my boot disk, it's the storage disk, I'm going to re-disklabel, and newfs it; Do I also need to do something with fdisk? I'm not sure... Yes, that is recommended. If yo use the whole disk for OpenBSd, As I do. fdisk -i will do. B B B B -Otto Ok.
Re: impact of unaligned partitions/slices on 4kB sector drives (wd10ears)
On Sat, May 14, 2011 at 04:15:51AM -0500, Abel Abraham Camarillo Ojeda wrote: On Sat, May 14, 2011 at 4:08 AM, David Gwynne l...@animata.net wrote: i have had a look at querying disks for their physical and logical block alignments and offsets, but the the WD??EARS-00? drives dont report this info. according to western digital, the next generation of these drives (WD??EARS-11? iirc) are supposed to report them. if i ever find a disk that does report the physical to logical alignment, i might have a look at having the system make use of those values. Yes, this is exactly the last thing I remember about this topic. huggz, dlg This isn't my boot disk, it's the storage disk, I'm going to re-disklabel, and newfs it; Do I also need to do something with fdisk? I'm not sure... Yes, that is recommended. If yo use the whole disk for OpenBSd, fdisk -i will do. -Otto
Re: impact of unaligned partitions/slices on 4kB sector drives (wd10ears)
1) Don't cross post. 2) Install something more recent that 4.6 (e.g. 4.9) and you will find that partitions and filesystems will be aligned on 4K boundaries. 3) If you can, without trying hard, end up with misaligned partitions on a fresh 4.9 install then please detail the steps you followed and I for one would be very interested. Ken On Sat, May 14, 2011 at 03:43:23AM -0500, Abel Abraham Camarillo Ojeda wrote: List: openbsd-tech Subject:impact of unaligned partitions/slices on 4kB sector drives (wd10ears) From: Robert robert () openbsd ! pap ! st Date: 2010-01-06 22:54:34 Message-ID: 20100106235434.55963d32 () openbsd ! pap ! st Hello, i did some measurements on the impact that unaligned partitions/slices have on the new harddrives that use ondisk 4kB sectors and export them as 512B sectors. [1] My tests were done on a Western Digital WD10EARS. [2] CONCLUSION: Having unaligned partition/slices on those disks leads to noticable performance penalty under realworld workloads. IMPLICATIONS: 1. The rounding of unit sizes to cylinder boundaries by disklabel has to be evaluated. 2. A FAQ entry for the advanced format disks is needed to tell people to set the XP jumper. (more on that later) If disklabel is not modified, that entry would also have to explain the alignement implications and how to use a calculator. TEST RESULTS: - sequential write/read speeds --- dd bs | aligned | unaligned | wd10eads* | | | 4k write | 97433116 | 86349673 | 80762241 (bytes/sec) 64k w | 101273894 | 85616298 | 81234814 1m w | 98291974 | 79201231 | 83113302 | | | 4k read | 103706513 | 104434701 | 82723667 64k r | 105136468 | 104453140 | 85552816 1m r | 104228605 | 104921901 | 85650289 (* wd10eads is the previous generation to the wd10ears with 32mb cache and usual 512B ondisk sectors. Disk is in a different system! That system is not idle so actual numbers might be higher.) - extracting a source tree --- aligned : 6m26.31s unaligned : 14m30.30s - build kernel / make obj / make build --- | aligned | unaligned kernel | 2m27.94s | 2m48.12s make obj | 0m28.51s | 1m01.41s make build | 36m07.27s | 70m51.58s EXPLANAITIONS (or whatever :): Those numbers are kinda scary. I would not have expected such bad results for the builds from my earlier sequential rw tests i sent to misc@. (Just to make it clear, if the partition/slices are not aligned, the disk has to read every 4k sector it wants to write to, before it can actually do that. The 64MB of cache help to elevate that up to some point.) This drive has a XP legacy jumper. (Same as WD15EARS and WD20EARS.) It is intended to be used for Windows XP systems with a single partition over the whole drive. XP uses the same 63 sector offset as OpenBSD does. Setting this jumper, transparently alignes the 63 sectors infront of a 4k sector boundary. When that jumper is set, slices inside the partition only have to be multiples of 8 big. The issue is with disklables rounding down to the nearest cylinder boundary. This will mess up the nice multiplication by 1024, which would lead to a size divisable by 8. The rounding down is always done when using units, but not when requesting a size without a unit/in sectors. So slices can be aligned that way by hand. That rounding to cylinders is not needed, afaik. So without that, a simple rtfaq! set the damn jumper! would be enough, to get the best performance out of such harddisks. Below you can find more info about my test setup and the test outputs. Cheers, - Robert [1] http://www.wdc.com/advformat [2] http://www.wdc.com/en/products/products.asp?driveidv3 TESTS: aligned == XP jumper set unaligned == XP jumper NOT set* (* without the jumper, the partition/slices are off by one 512B sector.) I installed a snapshot i had on hand (see dmesg) and went from there. (Fresh installl without the jumper.) Source-tree used is -current from some hours ago. I sync'ed before every test. disk layout and ramdisk was the same in both scenarios. - dmesg --- OpenBSD 4.6-current (GENERIC.MP) #40: Tue Dec 29 01:02:20 MST 2009 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 3488088064 (3326MB) avail mem = 3388391424 (3231MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xf0730 (61 entries) bios0: vendor American Megatrends Inc. version 1104 date 09/11/2009 bios0: ASUSTeK Computer INC. P5QL-E acpi0 at bios0: rev 2 acpi0: tables DSDT FACP APIC MCFG OEMB HPET OSFR acpi0: wakeup devices P0P2(S4) P0P3(S4) P0P1(S4) UAR1(S4) PS2K(S4) PS2M(S4) EUSB(S4) \ USBE(S4) P0P5
