Re: impact of unaligned partitions/slices on 4kB sector drives (wd10ears)
On Sat, May 14, 2011 at 9:14 PM, Kenneth R Westerback 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)
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 > 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 j
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 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)
On Sat, May 14, 2011 at 4:22 AM, Otto Moerbeek 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 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 4:08 AM, David Gwynne 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 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-tech&m=126281899324219&w=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: con
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-tech&m=126281899324219&w=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
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)
List: openbsd-tech Subject:impact of unaligned partitions/slices on 4kB sector drives (wd10ears) From: Robert 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) P
