On Thu, May 01, 2014 at 09:06:49AM +0200 or thereabouts, Remco wrote: > >> fdisk before > >> ============ > >> > >> Disk: /dev/rsd0c geometry: 121601/255/63 [1953523055 Sectors] > >> Offset: 0 Signature: 0xAA55 > >> Starting Ending LBA Info: > >> #: id C H S - C H S [ start: size ] > >> > > ----------------------------------------------------------------------------- > > -- > >> 0: A6 0 32 33 - 121601 25 24 [ 2048: 1953519616 ] > > OpenBSD > >> 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] > >> unused > >> 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] > >> unused > >> 3: 00 0 0 0 - 0 0 0 [ 0: 0 ] > >> unused > > Did you guys see my mail yesterday ? (albeit responding to the "Problem > booting OpenBSD-current AMD64" thread) > > First of all I'd expect OpenBSD to create its fdisk partition on the > partition > with id 3, starting at LBA offset 64. (don't know if this changed) > > Is the partition 0 starting at offset 2048 a Linux left-over ? > > Anyway, my Gigabyte board used to work fine with a fdisk partition starting > at > either offset 63 or 64, respectively. Not so much after installing Linux the > other day, which put the starting offset at 2048. > > This happens using the on-board Intel AHCI controller. Fortunately my board > also has a non-Intel controller which does work, so being able to use that I > didn't put more time into investigating this. >
So far as I am aware, MS then linux moved the offset due to an accidental discovery of possible performance improvements. For example: from http://www.rodsbooks.com/gdisk/advice.html Partition Alignment Issues MBR disks often use partitions that begin only on sectors that are multiples of 63. This is because modern hard disks almost always appear to have 63 sectors per cylinder in the CHS geometry scheme, and partitioning tools have traditionally begun partitions on cylinder boundaries. (Disks with other than 63 sectors per cylinder will have other sector alignments on MBR disks, of course.) Today, though, CHS geometries are largely fictions, so these partition placement rules serve no real purpose, aside from keeping old OSes and utilities happy. Some recent MBR partitioning tools, including those that ship with Windows Vista and later, therefore abandon these old rules in favor of rules that are designed to satisfy newer issues: Starting in December of 2009, disk manufacturers began introducing models that employ 4096-byte (4 KiB) physical sectors but present 512-byte logical sectors to the OS. When the OS writes eight contiguous logical sectors that make up a physical sector, the drive can simply write the new physical sector; however, whenever the OS writes just one to seven logical sectors of a physical sector, the entire physical sector must be read, modified, and re-written. RAID5 and RAID6 work by creating "stripes" of data. Each disk has many stripes, and each stripe on each disk is associated with matching stripes on the other disks. Another disk or two have stripes that record parity information for the main disks' stripes, or the parity data may be spread across all the disks. In either case, whenever any data in the matched stripes on any of the disks is changed, the parity data must be updated. In both of these cases, performance can be degraded if partitions are not properly aligned. You should first understand that modern filesystems employ data structures that are 4 KiB, or larger multiples of that amount, in size. Thus, when an OS modifies one of these filesystem data structures on a disk with a smaller logical than physical sector size or on a RAID array, performance will be optimized if the partition is aligned to match the underlying disk sector or stripe size. If the partition is not so aligned, the write operation will entail an extra read operation (for disks with 4096-byte physical sectors) or writing to two stripes even for small writes. Such operations take extra time, and so disk write performance can be impacted. Depending on the filesystem in use, performance when writing many small files to disks with 4096-byte physical sectors can be degraded by as much as a factor of 25 in benchmarks I've run-that is, an operation that takes one second on a prope! rly-aligned partition can take up to 25 seconds on a misaligned partition! (My full writeup on the issue appears on the IBM developerWorks site.) Issues surrounding RAID requirements are similar, but not as dramatic. Web sites I've consulted, such as this page on Linux hardware RAID optimization, or a Microsoft page on SQL administration, claim a 10-40% performance difference between properly aligned and misaligned partitions. Regards Moss
