ATA 4 KiB sector issues.

Hello, guys.

It looks like transition to ATA 4k drives will be quite painful and we aren't really ready although these drives are already selling widely. I've written up a summary document on the issue to clarify stuff as it's getting more and more confusing and develop some consensus.  It's also on the linux ata wiki.

 http://ata.wiki.kernel.org/index.php/ATA_4_KiB_sector_issues

I've cc'd people whom I can think of off the top of my head but I surely have missed some people who would have been interested.  Please feel free to add cc's or forward the message to other MLs. Especially, I don't know much about partitioners so the details there are pretty shallow and could be plain wrong.  It would be great if someone who knows more about this stuff can chime in.

Thanks.

=== Document follows ===

ATA 4 KiB sector issues

Background
==========

Up until recently, all ATA hard drives have been organized in 512 byte sectors.  For example, my 500 GB or 477 GiB hard drive is organized of 976773168 512 byte sectors numbered from 0 to 976773167.  This is how a drive communicates with the driver.  When the operating system wants to read 32 KiB of data at 1 MiB position, the driver asks the drive to read 64 sectors from LBA (Logical block address, sector number) 2048.

Because each sector should be addressable, readable and writable individually, the physical medium also is organized in the same sized sectors.  In addition to the area to store the actual data, each sector requires extra space for book keeping - inter-sector space to enable locating and addressing each sector and ECC data to detect and correct inevitable raw data errors.

As the densities and capacities of hard drives keep growing, stronger ECC becomes necessary to guarantee acceptable level of data integrity increasing the space overhead.  In addition, in most applications, hard drives are now accessed in units of at least 8 sectors or 4096 bytes and maintaining 512 byte granularity has become somewhat meaningless.

This reached a point where enlarging the sector size to 4096 bytes would yield measurably more usable space given the same raw data storage size and hard drive manufacturers are transitioning to 4 KiB sectors.

Anandtech has a good article which illustrates the background and issues with pretty diagrams[1].

Physical vs. Logical
====================

Because the 512 byte sector size has been around for a very long time and upto ATA/ATAPI-7 the sector size was fixed at 512 bytes, the sector size assumption is scattered across all the layers - controllers or bridge chips snooping commands, BIOSs, boot codes, drivers, partitioners and system utilities, which makes it very difficult to change the sector size from 512 byte without breaking backward compatibility massively.

As a workaround, the concept of logical sector size was introduced. The physical medium is organized in 4 KiB sectors but the firmware on the drive will present it as if the drive is composed of 512 byte sectors thus making the drive behave as before, so if the driver asks the hard drive to read 64 sectors from LBA 2048, the firmware will translate it and read 8 4 KiB sectors from hardware sector 256.  As a result, the hard drive now has two sector sizes - the physical one which the physical media is actually organized in, and the logical one which the firmware presents to the outside world.

A straight forward example mapping between physical sector and LBA would be

 LBA = 8 * phys_sect

Alignment problem on 4 KiB physical / 512 logical drives
=======================================================

This workaround keeps older hardware and software working while allowing the drive to use larger sector size internally.  However, the discrepancy between physical and logical sector sizes creates an alignment issue.  For example, if the driver wants to read 7 sectors from LBA 2047, the firmware has to read hardware sector 255 and 256 and trim leading 7*512 bytes and tailing 512 bytes.

For reads, this isn't an issue as drives read in larger chunks anyway but for writes, the drive has to do read-modify-write to achieve the requested action.  It has to first read hardware sector 255 and 256, update requested parts and then write back those sectors which can cause significant performance degradation[2].

The problem is aggravated by the way DOS partitions[3] have been laid out traditionally.  For reasons dating back more than two decades, they are laid out considering something called disk geometry which nowadays are arbitrary values with a number of restrictions for backward compatibility accumulated over the years.  The end result is that until recently (most Linux variants and upto Windows XP) the first partition ends up on sector 63 and later ones on cylinder boundaries where each cylinder usually is composed of 255 * 63 sectors.

Most modern filesystems generate 4 KiB aligned accesses from the partition it is in.  If a drive maps 4 KiB physical sectors to 512 byte logical sectors from LBA0, the filesystem in the first partition will always be misaligned and filesystems in later partitions are likely to be misaligned too.

Solving the alignment problem on 4 KiB physical / 512 logical drives
====================================================================

There are multiple ways which attempt to solve the problem.

S-1. Yet another workaround from the firmware - offset-by-one.

 Yet another workaround which can be done by the firmware is to offset physical to logical mapping by one logical sector such that LBA 63 ends up on physical sector boundary, which aligns the first partition to physical sectors without requiring any software update. The example mapping between phys_sector and LBA becomes

   LBA = 8 * phys_sect - 1

 The leading 512 bytes from phys_sect 0 is not used and LBA 0 starts from after that point.  phys_sect 1 maps to LBA 7 and phys_sect 8 to 63, making LBA 63 aligned on hardware sector.

 Although this aligns only the first partition, for many use cases, especially the ones involving older software, this workaround was deemed useful and some recent drives with 4 KiB physical sectors are equipped with a dip switch to turn on or off offset-by-one mapping.

S-2. The proper solution.

 Correct alignments for all partitions can't be achieved by the firmware alone.  The system utilities should be informed about the alignment requirements and align partitions accordingly.

 The above firmware workaround complicates the situation because the two different configurations require different offsets to achieve the correct alignments.  ATA/ATAPI-8 specifies a way for a drive to export the physical and logical sector sizes and the LBA offset which is aligned to the physical sectors.

 In Linux, these parameters are exported via the following sysfs nodes.

   physical sector size        : /sys/block/sdX/queue/physical_block_size logical sector size         : /sys/block/sdX/queue/logical_block_size alignment offset            : /sys/block/sdX/alignment_offset

 Let the physical sector size be PSS, logical sector size LSS and alignment offset AOFF.  The system software should place partitions such that the starting LBAs of all partitions are aligned on

   (n * PSS + AOFF) / LSS

 For 4 KiB physical sector offset-by-one drives, PSS is 4096, LSS 512 and AOFF 3584 and with n of 7 the above becomes,

   (7 * 4096 + 3584) / 512 == 63

 making sector 63 an aligned LBA where the first partition can be put, but without the offset-by-one mapping, AOFF is zero and LBA 63 is not aligned.

 With the above new alignment requirement in place, it becomes difficult to honor the legacy one - first partition on sector 63 and all other partitions on cylinder boundary (255 * 63 sectors) - as the two alignment requirements contradict each other.  This might be worked around by adjusting how LBA and CHS addresses are mapped but the disk geometry parameters are hard coded everywhere and there is no reliable way to communicate custom geometry parameters.

Complications
=============

Unfortunately, there are complications.

C-1. The standard is not and won't be followed as-is.

 Some of the existing BIOSs and/or drivers can't cope with drives which report 4 KiB physical sector size.  To work around this, some drive models lie that its physical sector size is 512 bytes when the actual configuration is 4 KiB without offsetting.

 This nullifies the provisions for alignment in the ATA standard but results in the correct alignment for Windows Vista and 7.  OS behaviors will be described further later.

 For these drives, which are likely to continue to be shipped for the foreseeable future, traditional LBA 63 and cylinder based aligning results in misalignment.

C-2. Windows XP depends on the traditional partition layout.

 Windows XP makes use of the CHS start/end addresses in the partition table and gets confused if partitions are not laid out traditionally.  This means that XP can't be installed into a partition prepared by later versions of Windows[4].  This isn't a big problem for Windows because in most cases the later version is replacing the older one, not the other way around.

 Unfortunately, the situation is more complex for Linux because Linux is often co-installed with various versions of Windows and XP is still quite popular.  This means that when a Linux partitioner is used to prepare a partition which may be used by Windows, the partitioner might have to consider which version of Windows is going to be used and whether to align the partitions for the correct alignment or compatibility with older versions of Windows.

C-3. The 2 TiB barrier and the possibility for 4 KiB logical sector size.

 The DOS partition format uses 32 bit for the starting LBA and the number of sectors and, reportedly, 32 bit Windows XP shares the limitation.  With 32 bit addressing and 512 byte logical sector size, the maximum addressable sector + 1 is at

   2^32 * 2^9 == 2^41 == 2 TiB

 The DOS partition format allows a partition to reach beyond 2 TiB as long as the starting LBA is under 2 TiB; however, both Windows XP and and the Linux kernel (at least upto v2.6.33) refuse such partition configurations.

 With the right combination of host controller, BIOS and driver, this barrier can be overcome by enlarging the logical sector size to 4 KiB, which will push the barrier out to 16 TiB.  On the right configuration, Windows XP is reportedly able to address beyond the 2 TiB barrier with a DOS partition and 4 KiB logical sector size. Linux kernel upto v2.6.33 doesn't work under such configurations but a patch to make it work is pending[5].

 This might also be beneficial for operating systems which don't suffer from this limitation.  A different partition format - GPT[6]
 - should be used beyond 2^32 sectors, which could harm compatibility with older BIOSs or other operating systems which don't recognize the new format.

 As mentioned previously, 512 byte sector assumption has been there for a very long time and changing it is likely to cause various compatibility problems at many different layers from hardware up to the system utilities.

Windows
=======

As hard drive vendors aim for performance and compatibility in modern Windows environments, it is worthwhile to investigate how Windows partitions with different alignment requirements.  Up until Windows XP, it followed the traditional layout - the first partition on LBA 63 and the others on cylinder boundaries where a cylinder is defined as 255 tracks with 63 sectors each.

Windows Vista and 7 align partitions differently.  As the two behave similarly, only 7's behavior is shown here.  These partition tables are created by Windows 7 RC installer on blank disks.

W-1. 512 byte physical and logical sector drive.

 ST FIRST  T  LAST   LBA      NBLKS
 80 202100 07 df130c 00080000 00200300
 00 df140c 07 feffff 00280300 00689e12
 00 000000 00 000000 00000000 00000000
 00 000000 00 000000 00000000 00000000

 Part0:        FIRST   C    0  H   32  S   33  : 2048          (63 sec/trk) LAST    C   12  H  223  S   19  : 206847        (255 heads/cyl) LBA     2048 + 204800 = 206848

 Part1:        FIRST   C   12  H  223  S   20  : 206848 LAST    C 1023  H  254  S   63  : E LBA     206848 + 312371200 = 312578048

 Both aligned at (2048 * n).  Part 1 not aligned to cylinder.

W-2. 4 KiB physical and 512 byte logical sector drive without offset-by-one.

 ST FIRST  T  LAST   LBA      NBLKS
 80 202100 07 df130c 00080000 00200300
 00 df140c 07 feffff 00280300 00b83f25
 00 000000 00 000000 00000000 00000000
 00 000000 00 000000 00000000 00000000

 Part0:        FIRST   C    0  H   32  S   33  : 2048          (63 sec/trk) LAST    C   12  H  223  S   19  : 206847        (255 heads/cyl) LBA     2048 + 204800 = 206848

 Part1:        FIRST   C   12  H  223  S   20  : 206848 LAST    C 1023  H  254  S   63  : E LBA     206848 + 624932864 = 625139712

 Both aligned at (2048 * n).  Part 1 not aligned to cylinder.

W-3. 4 KiB physical and 512 byte logical sector drive with offset-by-one.

 ST FIRST  T  LAST   LBA      NBLKS
 80 202800 07 df130c 07080000 f91f0300
 00 df1b0c 07 feffff 07280300 f9376d74
 00 000000 00 000000 00000000 00000000
 00 000000 00 000000 00000000 00000000

 Part0:        FIRST   C    0  H   32  S   40  : 2055          (63 sec/trk) LAST    C   12  H  223  S   19  : 206847        (255 heads/cyl) LBA     2055 + 204793 = 206848

 Part1:        FIRST   C   12  H  223  S   27  : 206855 LAST    C 1023  H  254  S   63  : E LBA     206855 + 1953314809 = 1953521664

 Both aligned at (2048 * n + 7).  Part 1 not aligned to cylinder.

The partitioner seems to be using 1M as the basic alignment unit and offsetting from there if explicitly requested by the drive and there is no difference between handling of 512 byte and 4 KiB drives, which explains why C-1 works for hard drive vendors.

In all cases, the partitioner ignores both the first partition on LBA 63 and the others on cylinder boundary requirements while still using the same 255*63 cylinder size.  Also, note that in W-3, both part 0 and 1 end up with odd number of sectors.  It seems that they simply decided to completely break away from the traditional layout, which is understandable given that there really isn't one good solution which can cover all the cases and that the default larger alignment benefits earlier SSDs.

Windows Vista basically shows the same behavior.  Vista was tested by creating two partitions using the management tool.  Test data is available at [7].

 *-alignment_offset    : alignment_offset reported by Linux kernel *-fdisk               : fdisk -l output
 *-fdisk-u             : fdisk -lu output
 *-hdparm              : hdparm -I output
 *-mbr                 : dump of mbr
 *-part                : decoded partition table from mbr

Please note that hdparm is misreporting the alignment offset.  It should be reporting 512 instead of 256 for offset-by-one drives.

So, what now for Linux?
=======================

The situation is not easy.  Considering all the factors, the only workable solution looks like doing what Windows is doing.  Hard drive and SSD vendors are focusing on compatibility and performance on recent Windows releases and are happy to do things which break the standard defined mechanism as shown by C-1, so parting away from what Windows does would be unnecessarily painful.

Unfortunately, while Windows can assume that newer releases won't share the hard drive with older releases including Windows XP, Linux distros can't do that.  There will be many installations where a modern Linux distros share a hard drive with older releases of Windows.  At this point, I can't see a silver bullet solution.

Partitioners maybe should only align partitions which will be used by Linux and default to the traditional layout for others while allowing explicit override.  I think Windows XP wouldn't have problem with differently aligned partitions as long as it doesn't actually use them but haven't tested it.

Reportedly, commonly used partitioners aren't ready to handle drives larger than 2 TiB in any configuration and alignment isn't done properly for drives with 4 KiB physical sectors.  4 KiB logical sector support is broken in both the kernel and partitioners.  (need more details and probably a whole section on partitioner behaviors)

Unfortunately, the transition to 4 KiB sector size, physical only or logical too, is looking fairly ugly.  Hopefully, a reasonable solution can be reached in not too distant future but even with all the software side updated, it looks like it's gonna cause significant amount of confusion and frustration.

[1] http://www.anandtech.com/storage/showdoc.aspx?i=3691
[2] http://www.osnews.com/story/22872/Linux_Not_Fully_Prepared_for_4096-Byte_Sector_Hard_Drives
[3] http://en.wikipedia.org/wiki/Master_boot_record
[4] http://support.microsoft.com/kb/931760
[5] http://thread.gmane.org/gmane.linux.kernel/953981
[6] http://en.wikipedia.org/wiki/GUID_Partition_Table
[7] http://userweb.kernel.org/~tj/partalign/

* Mar 04 2009
       Initial draft, Tejun Heo <[email protected]>
* Mar 08 2009
       Updated according to comments from Daniel Taylor <[email protected]>.  Other minor updates.
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Just a quick note:

The 2TB size for msdos partitions is a problem independent of the 4k sector issue. Traditional 512 byte sector drives are now available in those sizes. It looks like we're going to have to move to a new partitioning label to solve this.

There's actually another barrier at 8 or 16TB, which is where a 4k logical sector filesystem tops out using 32 bit block offsets (it's 8TB if the fs hasn't been proof checked against sign extension problems).

However, for 4k sectors, the main issues which have shown up in testing by others (mostly Martin) are

1. In native 4k mode, we work perfectly fine. *however*, most BIOSs can't boot native 4k drives.
2. Even if the BIOS can boot native 4k, our own boot loaders seem to be hard coded for 512 byte sectors in several places.
3. If we run in the 512 byte sector emulation mode, we end up with the partition alignment problems you allude to.
4. The aligment problem is made more complex by drives that make use of the offset exponent feature (what you refer to as offset by one) ... fortunately very few of these have been seen in the wild and we're hopeful they can be shot before they breed.
5. I'm really, really sorry to have to mention it, but it looks like uefi is going to be the only way we can boot non-msdos partitioned devices with native 4k sectors.

so the bottom line seems to be that if you want the device as a non boot disk, use native 4k sectors and a non-msdos partition label. If you want to boot from the drive and your bios won't book 4k natively, partition everything using the 512 emulation and try to align the partitions correctly. If your bios/uefi will boot 4k natively, just use it and whatever partition label the bios/uefi supports.

Martin can fill in the pieces I've left out.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"hpa" == H Peter Anvin <[email protected]> writes:

As far as partitioning... I believe we should be using GPT partition tables where possible.  Even on non-EFI systems, it's simply a much better partition table format.

       -hpa

Quoted 3 lines

As far as partitioning... I believe we should be using GPT partition tables where possible. Even on non-EFI systems, it's simply a much better partition table format.

GPT can not be used for boot disks in non-EFI systems, right?

Quoted 2 lines

GPT can not be used for boot disks in non-EFI systems, right?

IIUC, I think any BIOS should be able to do so as it only cares about the

not the partitions and even with GPT the MBR remains the same with the

describing the rest of the while disk as a single chunk containing GPT

only problem is the older operating systems (like XP) which don't

able to access those partitions.

Thanks.

The MBR in a GPT installation doesn't map the first GPT partition, it maps the entire drive drive after the first sector, as well as marking it type 0xEE.

The start LBA of the file system is not correctly located in the MBR.

I will run some experiments to see if any of the systems on my desk can boot Linux from a GPT.

Quoted 3 lines

I will run some experiments to see if any of the systems on my desk can boot Linux from a GPT.

I'm not sure about grub although I strongly suspect recent version of it should work but AFAICS lilo should definitely work as it doesn't care how the disk is logically organized at all.

The MBR in a GPT installation doesn't map the first GPT partition, it maps the entire drive
drive after the first sector, as well as marking it type 0xEE. The start LBA of the file system
is not correctly located in the MBR.

I will run some experiments to see if any of the systems on my desk can boot Linux from a GPT.

I will run some experiments to see if any of the systems on my desk can boot Linux from a GPT.

<snip>

Quoted 6 lines

As far as partitioning... I believe we should be using GPT partition tables where possible. Even on non-EFI systems, it's simply a much better partition table format.

-hpa

GPT can not be used for boot disks in non-EFI systems, right?

It can. The BIOS doesn't care about the partition table at all -- all it does is load the MBR.

Quoted 3 lines · H. Peter Anvin

It can. The BIOS doesn't care about the partition table at all -- all it does is load the MBR.

A little story for your entertainment pleasure:

I have a Gigabyte GA-MA78GM-S2H board, and during install turned off the power after partitioning but before formatting any partition because I got distracted by something else.

Result: System could not boot anymore, BIOS hung before I could get to the "select boot device" screen. This also happened when I removed the hdd from the boot device list in BIOS. The last BIOS message was "Verifying DMI Pool Data" and you can find numerous similar reports by searching for 'gigabyte bios hang "Verifying DMI Pool Data"'.

In my case it worked to switch the SATA mode from AHCI to something else, then wipe the partition table and switch back to AHCI. But I read on the net that some people had to format the drive in another PC, or hotplug it after the BIOS got past "Verifying DMI Pool Data".

The 2TB size for msdos partitions is a problem independent of the 4k sector issue. Traditional 512 byte sector drives are now available in those sizes. It looks like we're going to have to move to a new partitioning label to solve this.

There's actually another barrier at 8 or 16TB, which is where a 4k logical sector filesystem tops out using 32 bit block offsets (it's 8TB if the fs hasn't been proof checked against sign extension problems).

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"James" == James Bottomley <[email protected]> writes:

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Martin" == Martin K Petersen <[email protected]> writes:

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

"Martin" == Martin K Petersen <[email protected]> writes:

"Martin" == Martin K Petersen <[email protected]> writes:

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

"Martin" == Martin K Petersen <[email protected]> writes:

"Martin" == Martin K Petersen <[email protected]> writes:

Martin> There are 4 KB LBS SSDs out there but in general the industry is Martin> sticking to ATA for local boot.

Martin> Thus implying that ATA doesn't support 4 KB LBS, just that Martin> people stick to the tried-and-true 512.

*sigh* I haven't had my breakfast tea yet...

What I meant to say was that I know ATA supports 4 KB LBS and that nobody appears to care about it.

Quoted 6 lines · Martin K. Petersen

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

"Martin" == Martin K Petersen <[email protected]> writes:

"Martin" == Martin K Petersen <[email protected]> writes:

Martin> There are 4 KB LBS SSDs out there but in general the industry is Martin> sticking to ATA for local boot.

Quoted 8 lines

Martin> Thus implying that ATA doesn't support 4 KB LBS, just that Martin> people stick to the tried-and-true 512.

*sigh* I haven't had my breakfast tea yet...

What I meant to say was that I know ATA supports 4 KB LBS and that nobody appears to care about it.

Well, apparently Western Digital are looking at it for USB drives due to XP compatibility requirements -- those presumably are ATA internally and use a USB-ATA bridge.

On the flipside, though, there really is very little net benefit to 4K as opposed to 512 byte logical sectors: the additional protocol overhead is relatively minimal, and as long as writes are aligned full blocks, there shouldn't be any additional overhead on either the OS or the drive side. On the plus side, you get full compatibility with the existing software stack. The equation really seems rather simple.

Quoted 7 lines

On the flipside, though, there really is very little net benefit to 4K as opposed to 512 byte logical sectors: the additional protocol overhead is relatively minimal, and as long as writes are aligned full blocks, there shouldn't be any additional overhead on either the OS or the drive side. On the plus side, you get full compatibility with the existing software stack. The equation really seems rather simple.

There's another problem that afflicts 4k drives emulating 512b: they have to do a read modify write for any isolated 512b write ... that leads to potential corruption of adjacent 512b blocks if power is lost at the moment the write is being done. Since most Linux filesystems are 4k sectors, misalignment really hammers this, plus most journal writes seem to be done in 512 byte increments. I suppose for USB this could be regarded as flakey as usual, though.

There's another problem that afflicts 4k drives emulating 512b: they have to do a read modify write for any isolated 512b write ... that leads to potential corruption of adjacent 512b blocks if power is lost at the moment the write is being done. Since most Linux filesystems are 4k sectors, misalignment really hammers this, plus most journal writes seem to be done in 512 byte increments. I suppose for USB this could be regarded as flakey as usual, though.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Cláudio" == Cláudio Martins <[email protected]> writes:

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"hpa" == H Peter Anvin <[email protected]> writes:

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"hpa" == H Peter Anvin <[email protected]> writes:

hpa> On the flipside, though, there really is very little net benefit to hpa> 4K as opposed to 512 byte logical sectors: the additional protocol hpa> overhead is relatively minimal, and as long as writes are aligned hpa> full blocks, there shouldn't be any additional overhead on either hpa> the OS or the drive side. On the plus side, you get full hpa> compatibility with the existing software stack. The equation hpa> really seems rather simple.

4KB sectors are not a win for anybody except the drive vendors.

There is a push in the industry right now to keep the 512-byte logical blocks forever. The first step would be to report misaligned accesses or accesses that are not a multiple of the physical block size. Second step would be to eventually reject any write that's not a properly aligned multiple of the physical block size.

Well, apparently Western Digital are looking at it for USB drives due to XP compatibility requirements -- those presumably are ATA internally and use a USB-ATA bridge.

On the flipside, though, there really is very little net benefit to 4K as opposed to 512 byte logical sectors: the additional protocol overhead is relatively minimal, and as long as writes are aligned full blocks, there shouldn't be any additional overhead on either the OS or the drive side. On the plus side, you get full compatibility with the existing software stack. The equation really seems rather simple.

What I meant to say was that I know ATA supports 4 KB LBS and that nobody appears to care about it.

Quoted 2 lines · Martin K. Petersen

What I meant to say was that I know ATA supports 4 KB LBS and that nobody appears to care about it.

I sent patches to add support ... they were ignored.

S-2. The proper solution.

Correct alignments for all partitions can't be achieved by the firmware alone. The system utilities should be informed about the alignment requirements and align partitions accordingly.

The above firmware workaround complicates the situation because the two different configurations require different offsets to achieve the correct alignments. ATA/ATAPI-8 specifies a way for a drive to export the physical and logical sector sizes and the LBA offset which is aligned to the physical sectors.

In Linux, these parameters are exported via the following sysfs nodes.

physical sector size : /sys/block/sdX/queue/physical_block_size
logical sector size : /sys/block/sdX/queue/logical_block_size
alignment offset : /sys/block/sdX/alignment_offset

Let the physical sector size be PSS, logical sector size LSS and alignment offset AOFF. The system software should place partitions such that the starting LBAs of all partitions are aligned on

(n * PSS + AOFF) / LSS

For 4 KiB physical sector offset-by-one drives, PSS is 4096, LSS 512 and AOFF 3584 and with n of 7 the above becomes,

    (7 * 4096 + 3584) / 512 == 63

making sector 63 an aligned LBA where the first partition can be put, but without the offset-by-one mapping, AOFF is zero and LBA 63 is not aligned.

With the above new alignment requirement in place, it becomes difficult to honor the legacy one - first partition on sector 63 and all other partitions on cylinder boundary (255 * 63 sectors) - as the two alignment requirements contradict each other. This might be worked around by adjusting how LBA and CHS addresses are mapped but the disk geometry parameters are hard coded everywhere and there is no reliable way to communicate custom geometry parameters.

I have practically no knowledge of Linux' block device drivers, but is this really a partitioning issue? I think the problem is with the filesystems when clustering multiple blocks without knowledge of the sector alignment and sector size of the underlying block device. Maybe it is a better solution to adapt the filesystem buffer routine which reads/writes data from/to the block device?

Quoted 6 lines · Damian Lukowski

I have practically no knowledge of Linux' block device drivers, but is this really a partitioning issue? I think the problem is with the filesystems when clustering multiple blocks without knowledge of the sector alignment and sector size of the underlying block device. Maybe it is a better solution to adapt the filesystem buffer routine which reads/writes data from/to the block device?

No, it's really a partitioning issue. If the paging subsystem wants a 4k
block to fill a particular page, we need to read that 4k block into memory. If we need to swap out that 4k block, we need to write that 4k
block to swap space, or to the memory segment's backing store. If the
partition is misaligned by 512 bytes, this is simply not possible. The
file system has to do what is requested of it by its users, and the reality is that we need to do 4k aligned reads and writes with respect to the beginning of the partition, far more often than not.

Hence, if we want the best performance on 4k sector drives, the partition
needs to be aligned with respect to what is most desirable for the device in question.

I guess, what he meant was, to keep filesystem blocks aligned, even if the partition is not. Say if the partition is mis-aligned by 512-bytes, let the filesystem waste 4k-512bytes and keep it's blocks aligned. But it might be a case of over-engineering, possibly requiring disk format change.

Quoted 5 lines · Nikanth Karthikesan

I guess, what he meant was, to keep filesystem blocks aligned, even if the partition is not. Say if the partition is mis-aligned by 512-bytes, let the filesystem waste 4k-512bytes and keep it's blocks aligned. But it might be a case of over-engineering, possibly requiring disk format change.

Ah, yes, I agree with you; that's probably what he meant.

Sure, that's theoretically possible, but it would mean changing every single filesystem, and it would require a file system format change --- or at least a file system format extension.

It would seem to be way easier to simply fix the partitioning tools to do the right thing, though.

Quoted 7 lines · Theodore Tso

Quoted 5 lines · Nikanth Karthikesan

I guess, what he meant was, to keep filesystem blocks aligned, even if the partition is not. Say if the partition is mis-aligned by 512-bytes, let the filesystem waste 4k-512bytes and keep it's blocks aligned. But it might be a case of over-engineering, possibly requiring disk format change.

Quoted 8 lines

Ah, yes, I agree with you; that's probably what he meant.

Sure, that's theoretically possible, but it would mean changing every single filesystem, and it would require a file system format change --- or at least a file system format extension.

It would seem to be way easier to simply fix the partitioning tools to do the right thing, though.

Actually, it's a layering violation. The filesystem shouldn't need to probe the device layout ... particularly when there are complexities like is it logical 512 or physical, and if logical 512 on 4k does it have an offset exponent or not.

We can transmit certain abstractions of information up the stack (like stripe width for RAID arrays which should be the fs optimal write size), but for this type of alignment, which can be completely solved at the partition layer, the information should really stay there and the filesystem should "just work".

The real problem, here is just that partitioning-tools should create partitions that can work with both XP as well as Windows7. May be distro installers, should ask the user which compatibility he needs.

Quoted 3 lines · Nikanth Karthikesan

The real problem, here is just that partitioning-tools should create partitions that can work with both XP as well as Windows7. May be distro installers, should ask the user which compatibility he needs.

4k aligned sectors will *work* with Windows XP, will it not? It's just simply a matter of Windows XP, being really ancient, doesn't create properly alligned partitions by default.

And how often are we going to see Windows XP systems with these new 4k physical sector drives anyway, where the first OS to touch the partition is Windows XP? And in the case where this does happy, the resulting partition will be result in terribly performance for Windows XP as well as Linux.

What's the specific scenario which you are trying to solve, and how likely is it to occur in real life?

Quoted 3 lines · Nikanth Karthikesan

The real problem, here is just that partitioning-tools should create partitions that can work with both XP as well as Windows7. May be distro installers, should ask the user which compatibility he needs.

4k aligned sectors will *work* with Windows XP, will it not?  It's just simply a matter of Windows XP, being really ancient, doesn't create properly alligned partitions by default.

And how often are we going to see Windows XP systems with these new 4k physical sector drives anyway, where the first OS to touch the partition is Windows XP?  And in the case where this does happy, the resulting partition will be result in terribly performance for Windows XP as well as Linux.

What's the specific scenario which you are trying to solve, and how likely is it to occur in real life?

                                       - Ted

I do think the linux partitioners should provide a way to force a cylinder alignment. Tejun, I would like to see your doc describe how to force a win2k compatible partition layout.

Quoted 5 lines · Nikanth Karthikesan

I guess, what he meant was, to keep filesystem blocks aligned, even if the partition is not. Say if the partition is mis-aligned by 512-bytes, let the filesystem waste 4k-512bytes and keep it's blocks aligned. But it might be a case of over-engineering, possibly requiring disk format change.

Ah, yes, I agree with you; that's probably what he meant.

Sure, that's theoretically possible, but it would mean changing every single filesystem, and it would require a file system format change --- or at least a file system format extension.

It would seem to be way easier to simply fix the partitioning tools to do the right thing, though.

Quoted 5 lines · Nikanth Karthikesan

I guess, what he meant was, to keep filesystem blocks aligned, even if the partition is not. Say if the partition is mis-aligned by 512-bytes, let the filesystem waste 4k-512bytes and keep it's blocks aligned. But it might be a case of over-engineering, possibly requiring disk format change.

Ah, yes, I agree with you; that's probably what he meant.

Sure, that's theoretically possible, but it would mean changing every
single filesystem, and it would require a file system format change --- or at least a file system format extension.

It would seem to be way easier to simply fix the partitioning tools to do
the right thing, though.

But the actual problem here is that partitioning tools might create partitions that wont allow other operating-systems to boot. So it might be enough, if the partitioning tools just create partitions with (mis-)alignment requirement for Windows.

Quoted 7 lines · On Thursday 11 March 2010 19:58:11 Theodore Tso wrote:

Quoted 5 lines · Nikanth Karthikesan

I guess, what he meant was, to keep filesystem blocks aligned, even if the partition is not. Say if the partition is mis-aligned by 512-bytes, let the filesystem waste 4k-512bytes and keep it's blocks aligned. But it might be a case of over-engineering, possibly requiring disk format change.

Quoted 9 lines

Ah, yes, I agree with you; that's probably what he meant.

Sure, that's theoretically possible, but it would mean changing every single filesystem, and it would require a file system format change --- or at least a file system format extension.

It would seem to be way easier to simply fix the partitioning tools to do the right thing, though.

Yes. May be, just a simple but transparent device-mapper like mapping on top of the mis-aligned partition, to do the alignment. Then the file-system code need not change much.

But Linux already has device-mapper and Linux will not be affected with mis- aligned partitions, when we use LVM.

But the actual problem here is that partitioning tools might create partitions that wont allow other operating-systems to boot. So it might be enough, if the partitioning tools just create partitions with (mis-)alignment requirement for Windows.

mkp in particular, Jens, James, myself, and others implemented and refined the SCSI and block changes. kzak, jim meyering, hans de goede, hch, eric sandeen, bob peterson, myself and others updated all other I/O stack layers ranging from DM to LVM, libblkid, fdisk, parted to anaconda to mkfs.ext[234], mkfs.xfs, mkfs.gfs2 to virt-io and qemu.
FYI, all of these advances will be in Fedora 13 (quite a few are
already in Fedora 12).

I guess, what he meant was, to keep filesystem blocks aligned, even if the partition is not. Say if the partition is mis-aligned by 512-bytes, let the filesystem waste 4k-512bytes and keep it's blocks aligned. But it might be a case of over-engineering, possibly requiring disk format change.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Tejun" == Tejun Heo <[email protected]> writes:

Tejun> Partitioners maybe should only align partitions which will be Tejun> used by Linux and default to the traditional layout for others Tejun> while allowing explicit override.

I don't think we take the partition type into account. Karel?

Tejun> Reportedly, commonly used partitioners aren't ready to handle Tejun> drives larger than 2 TiB in any configuration and alignment isn't Tejun> done properly for drives with 4 KiB physical sectors. 4 KiB Tejun> logical sector support is broken in both the kernel

Huh, what? My homedir is on a 4KiB LBS/PBS drive and has been for ~2 years.

Tejun> Unfortunately, the transition to 4 KiB sector size, physical only Tejun> or logical too, is looking fairly ugly. Hopefully, a reasonable Tejun> solution can be reached in not too distant future but even with Tejun> all the software side updated, it looks like it's gonna cause Tejun> significant amount of confusion and frustration.

With regards to XP compatibility I don't think we should go too much out of our way to accommodate it. XP has been disowned by its master and I think virtualization will take care of the rest.

FWIW, recent fdisk has a command line flag that will enable/disable DOS compatible layout.

Quoted 4 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

"hpa" == H Peter Anvin <[email protected]> writes:

Huh, what? My homedir is on a 4KiB LBS/PBS drive and has been for ~2 years.

Quoted 3 lines

With regards to XP compatibility I don't think we should go too much out of our way to accommodate it. XP has been disowned by its master and I think virtualization will take care of the rest.

Quoted 2 lines

FWIW, recent fdisk has a command line flag that will enable/disable DOS compatible layout.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Tejun" == Tejun Heo <[email protected]> writes:

Tejun> The [Windows Vista/7] partitioner seems to be using 1M as the Tejun> basic alignment unit and offsetting from there if explicitly Tejun> requested by the drive

Yep.

Tejun> Please note that hdparm is misreporting the alignment offset.  It Tejun> should be reporting 512 instead of 256 for offset-by-one drives.

Already fixed.  Your hdparm must be old.

Tejun> Partitioners maybe should only align partitions which will be Tejun> used by Linux and default to the traditional layout for others Tejun> while allowing explicit override.

I don't think we take the partition type into account.  Karel?

Tejun> Reportedly, commonly used partitioners aren't ready to handle Tejun> drives larger than 2 TiB in any configuration and alignment isn't Tejun> done properly for drives with 4 KiB physical sectors.  4 KiB Tejun> logical sector support is broken in both the kernel

Huh, what?  My homedir is on a 4KiB LBS/PBS drive and has been for ~2 years.

Tejun> (need more details and probably a whole section on partitioner Tejun> behaviors)

I'm Cc:'ing Karel Zak and Jim Meyering who have been doing all the alignment work for fdisk and parted respectively.  Karel, Jim: The full writeup is here:

       http://ata.wiki.kernel.org/index.php/ATA_4_KiB_sector_issues

It'd be great if you guys could share what you have been doing to the tooling.

I've been keeping track of all the pieces in play, have coordinated with kzak and jim, and have a summary that offers some amount of macro detail (at the end I touch on parted and fdisk):

http://people.redhat.com/msnitzer/docs/io-limits.txt

Quoted 3 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Tejun" == Tejun Heo <[email protected]> writes:

http://people.redhat.com/msnitzer/docs/io-limits.txt

I've been keeping track of all the pieces in play, have coordinated with kzak and jim, and have a summary that offers some amount of macro detail (at the end I touch on parted and fdisk):

http://people.redhat.com/msnitzer/docs/io-limits.txt

Mike Snitzer wrote:
[]

Quoted 5 lines

I've been keeping track of all the pieces in play, have coordinated with kzak and jim, and have a summary that offers some amount of macro detail (at the end I touch on parted and fdisk):

http://people.redhat.com/msnitzer/docs/io-limits.txt

What I don't see in this thread and in this document is - any mention of linux md layer. I think it is the first candidate to test the whole thing, the easiest and most important one. I mean the alignment and "recommended I/O size" and all this similar stuff.

Think of a raid5 array - with all the mentioned good stuff in place fdisk should figure out to align partitions on the array stripe boundary, and should do that automatically. And this should be

most easy to debug/test, since the whole thing is controllable by kernel.

On Tue, Mar 09, 2010 at 09:53:37AM +0300, Michael Tokarev wrote:

Quoted 3 lines

Think of a raid5 array - with all the mentioned good stuff in place fdisk should figure out to align partitions on the array stripe boundary, and should do that automatically. And this should be

Yes. For userspace there is not a difference between RAID and non-RAID device -- the topology support in kernel provides unified API to all devices. It means we needn't any extra support for RAIDs in fdisk/parted. The userspace tools follow topology data from kernel.

The good thing with 1MiB default alignment is that it is usable for usual stripe sizes (for sizes greater than 1MiB we use optimal I/O size).

Quoted 2 lines

most easy to debug/test, since the whole thing is controllable by kernel.

I did almost all my tests with scsi_debug or MD RAID0 on scsi_debug. It works as expected.

Disk /dev/sdb: 2621 MB, 2621440000 bytes
255 heads, 63 sectors/track, 318 cylinders, total 5120000 sectors Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 32768 bytes

 # mdadm --create /dev/md8 --level=5 --raid-devices=4 /dev/sdb{1,2,3,4}

 # fdisk -lcu /dev/md8

Disk /dev/md8: 1572 MB, 1572667392 bytes
2 heads, 4 sectors/track, 383952 cylinders, total 3071616 sectors Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 65536 bytes / 65536 bytes

 # cat /sys/block/md8/md8p{1,2}/alignment_offset
 0
 0

Quoted 2 lines · Karel Zak

I did almost all my tests with scsi_debug or MD RAID0 on scsi_debug. It works as expected.

Actually, for raid0, the alignment is questionable. Should it be a multiple of chunk size or whole stripe size? I'm not sure, both ways has bad and good sides.. But if it is the latter, the same issues pops up again: do a 3-disk raid0 and you'll have to align to 3*2^N.

Quoted 7 lines · Michael Tokarev

Quoted 2 lines · Karel Zak

I did almost all my tests with scsi_debug or MD RAID0 on scsi_debug. It works as expected.

Actually, for raid0, the alignment is questionable. Should it be a multiple of chunk size or whole stripe size? I'm not sure, both ways has bad and good sides.. But if it is the latter, the same issues pops up again: do a 3-disk raid0 and you'll have to align to 3*2^N.

Yes, alignment is still needed, especially for filesystems that can do stripe unit aligned allocation like XFS. If you don't align the filesystem properly, all the data IO will be mis-aligned to the underlying disks and stripe unit sized IO will hit multiple disks rather than just one....

Quoted 9 lines · Dave Chinner

Quoted 7 lines · Michael Tokarev

Quoted 2 lines · Karel Zak

I did almost all my tests with scsi_debug or MD RAID0 on scsi_debug. It works as expected.

Actually, for raid0, the alignment is questionable. Should it be a multiple of chunk size or whole stripe size? I'm not sure, both ways has bad and good sides.. But if it is the latter, the same issues pops up again: do a 3-disk raid0 and you'll have to align to 3*2^N.

Quoted 5 lines

Yes, alignment is still needed, especially for filesystems that can do stripe unit aligned allocation like XFS. If you don't align the filesystem properly, all the data IO will be mis-aligned to the underlying disks and stripe unit sized IO will hit multiple disks rather than just one....

I understand alignment is needed, the question is if the alignment should be to chunk size or full-stripe size. In neither case it will be bad for underlying disks.

Quoted 1 line · Karel Zak

 # mdadm --create /dev/md8 --level=5 --raid-devices=4 /dev/sdb{1,2,3,4}

That's 3-disk stripe size with default 64Kb chunk size, which makes 3x64=320KiB - the number to which everything should be aligned.

Quoted 7 lines

 # fdisk -lcu /dev/md8

Disk /dev/md8: 1572 MB, 1572667392 bytes
2 heads, 4 sectors/track, 383952 cylinders, total 3071616 sectors Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 65536 bytes / 65536 bytes

And here we go: fdisk does not see the right number: nothing is dividable by 3.

[]

Quoted 3 lines

 # cat /sys/block/md8/md8p{1,2}/alignment_offset
 0
 0

And that's where the issue is. md does not {sup,re}port all this stuff yet.

This is what I'm talking about.

Quoted 1 line · Karel Zak

 # mdadm --create /dev/md8 --level=5 --raid-devices=4 /dev/sdb{1,2,3,4}

That's 3-disk stripe size with default 64Kb chunk size, which makes 3x64=320KiB - the number to which everything should be aligned.

Quoted 2 lines

 # fdisk -lcu /dev/md8

Quoted 5 lines

Disk /dev/md8: 1572 MB, 1572667392 bytes
2 heads, 4 sectors/track, 383952 cylinders, total 3071616 sectors Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 65536 bytes / 65536 bytes

And here we go: fdisk does not see the right number: nothing is dividable by 3.

Quoted 3 lines

 # cat /sys/block/md8/md8p{1,2}/alignment_offset
 0
 0

And that's where the issue is. md does not {sup,re}port all this stuff yet.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Karel" == Karel Zak <[email protected]> writes:

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Karel" == Karel Zak <[email protected]> writes:

[Cleaned up the CC: list from hell]

Karel> # cat /sys/block/md8/queue/{minimum,optimal}_io_size Karel> 65536 65536

This one had me puzzled. We set min_io and opt_io correctly in raid5.c depending on number of non-parity disks. And yet it turns into something nonsensical after.

Turns out we overrun unsigned int calculating the lowest common multiple in the stacking function. That's why we ended up with the wrong value.

I never noticed this because my userland topology regression test tool uses unsigned long.

I'll get a patch off to Jens right away.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Michael" == Michael Tokarev <[email protected]> writes:

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Tejun" == Tejun Heo <[email protected]> writes:

Tejun> Partitioners maybe should only align partitions which will be Tejun> used by Linux and default to the traditional layout for others Tejun> while allowing explicit override.

I don't think we take the partition type into account. Karel?

Tejun> Reportedly, commonly used partitioners aren't ready to handle Tejun> drives larger than 2 TiB in any configuration and alignment isn't

Tejun> done properly for drives with 4 KiB physical sectors. 4 KiB Tejun> logical sector support is broken in both the kernel

Huh, what? My homedir is on a 4KiB LBS/PBS drive and has been for ~2 years.

Tejun> (need more details and probably a whole section on partitioner Tejun> behaviors)

I'm Cc:'ing Karel Zak and Jim Meyering who have been doing all the alignment work for fdisk and parted respectively. Karel, Jim: The full writeup is here:

http://ata.wiki.kernel.org/index.php/ATA_4_KiB_sector_issues

It'd be great if you guys could share what you have been doing to the tooling.

Tejun> Unfortunately, the transition to 4 KiB sector size, physical only Tejun> or logical too, is looking fairly ugly. Hopefully, a reasonable Tejun> solution can be reached in not too distant future but even with Tejun> all the software side updated, it looks like it's gonna cause Tejun> significant amount of confusion and frustration.

With regards to XP compatibility I don't think we should go too much out of our way to accommodate it. XP has been disowned by its master and I think virtualization will take care of the rest.

FWIW, recent fdisk has a command line flag that will enable/disable DOS compatible layout.

Quoted 2 lines

Tejun> Reportedly, commonly used partitioners aren't ready to handle Tejun> drives larger than 2 TiB in any configuration and alignment isn't

The limit is specific for DOS partition table (with 512-byte log. sectors), but for example GPT uses 64-bit LBA. I believe that our partitioning tools don't introduce any other restriction.

Quoted 5 lines

Tejun> done properly for drives with 4 KiB physical sectors. 4 KiB Tejun> logical sector support is broken in both the kernel

Huh, what? My homedir is on a 4KiB LBS/PBS drive and has been for ~2 years.

Quoted 11 lines

Tejun> (need more details and probably a whole section on partitioner Tejun> behaviors)

I'm Cc:'ing Karel Zak and Jim Meyering who have been doing all the alignment work for fdisk and parted respectively. Karel, Jim: The full writeup is here:

http://ata.wiki.kernel.org/index.php/ATA_4_KiB_sector_issues

It'd be great if you guys could share what you have been doing to the tooling.

small summary:

- libblkid provides unified API to topology information, it supports:
- ioctls (kernel >= 2.6.32)
- sysfs (kernel >= 2.6.31)
- stripe chunk size and stripe width for DM, MD. LVM and evms on old kernels
- libparted and fdisk are linked against libblkid

- fdisk supports 4KiB logical sector size (util-linux-ng >= 2.15
- fdisk supports 4KiB physical sector size (util-linux-ng >= 2.17)
- fdisk uses 1MiB alignment (or more if optimal I/O size is bigger) and alignment_offset for all partitions in non-DOS mode (util-linux-ng >= 2.17.1)

- parted supports 4KiB physical sector size
- parted uses 1MiB alignment for disks with unknown topology, disks with topology information are aligned to optimal (or minimum) I/O size (parted >= 2.1)

- EFI GPT code in the kernel has been updated to works properly with 4KiB sectors (kernel >= 2.6.33)

- mkfs.{ext,xfs,gfs2,ocfs2} have been update to work properly with topology information, mkfs.{ext,xfs} are linked against libblkid for compatibility with old kernel (for stripe chunk size / width)

- Fedora-13/RHEL6 installer uses libparted with 4KiB support

- alignment_offset & 4KiB support is planned for LUKS (cryptsetup)

Quoted 9 lines

Tejun> Unfortunately, the transition to 4 KiB sector size, physical only Tejun> or logical too, is looking fairly ugly. Hopefully, a reasonable Tejun> solution can be reached in not too distant future but even with Tejun> all the software side updated, it looks like it's gonna cause Tejun> significant amount of confusion and frustration.

With regards to XP compatibility I don't think we should go too much out of our way to accommodate it. XP has been disowned by its master and I think virtualization will take care of the rest.

Quoted 2 lines

FWIW, recent fdisk has a command line flag that will enable/disable DOS compatible layout.

yes, util-linux-ng 2.17.1, fdisk -c

Note that non-DOS mode will be default in the next major util-linux-ng release.

libata is broken for logical 4KiB ATA devices tho. I'll fix it up.

Quoted 1 line · Tejun Heo

libata is broken for logical 4KiB ATA devices tho. I'll fix it up.

Does libata-dev.git#sectsize miss any details?

Quoted 3 lines

- parted uses 1MiB alignment for disks with unknown topology, disks with topology information are aligned to optimal (or minimum) I/O size (parted >= 2.1)

This will result in incorrect alignment for drives which lie about the physical sector size to work around BIOS/drivers issues (C-1). It would probably be best to align to at least 1MiB.

Quoted 5 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Tejun" == Tejun Heo <[email protected]> writes:

This will result in incorrect alignment for drives which lie about the physical sector size to work around BIOS/drivers issues (C-1). It would probably be best to align to at least 1MiB.

Quoted 4 lines

Quoted 4 lines

Quoted 1 line

Quoted 1 line

"Tejun" == Tejun Heo <[email protected]> writes:

Huh, what? My homedir is on a 4KiB LBS/PBS drive and has been for ~2 years.

Quoted 3 lines

Tejun> Reportedly, commonly used partitioners aren't ready to handle Tejun> drives larger than 2 TiB in any configuration and alignment Tejun> isn't

The limit is specific for DOS partition table (with 512-byte log. sectors), but for example GPT uses 64-bit LBA. I believe that our partitioning tools don't introduce any other restriction.

Quoted 5 lines

Tejun> done properly for drives with 4 KiB physical sectors. 4 KiB Tejun> logical sector support is broken in both the kernel

Huh, what? My homedir is on a 4KiB LBS/PBS drive and has been for ~2 years.

Quoted 11 lines

Tejun> (need more details and probably a whole section on partitioner Tejun> behaviors)

I'm Cc:'ing Karel Zak and Jim Meyering who have been doing all the alignment work for fdisk and parted respectively. Karel, Jim: The full writeup is here:

http://ata.wiki.kernel.org/index.php/ATA_4_KiB_sector_issues

It'd be great if you guys could share what you have been doing to the tooling.

small summary:

- libblkid provides unified API to topology information, it supports:
- ioctls (kernel >= 2.6.32)
- sysfs (kernel >= 2.6.31)
- stripe chunk size and stripe width for DM, MD. LVM and evms on old kernels
- libparted and fdisk are linked against libblkid

- fdisk supports 4KiB logical sector size (util-linux-ng >= 2.15
- fdisk supports 4KiB physical sector size (util-linux-ng >= 2.17)
- fdisk uses 1MiB alignment (or more if optimal I/O size is bigger) and alignment_offset for all partitions in non-DOS mode (util-linux-ng >= 2.17.1)

- parted supports 4KiB physical sector size
- parted uses 1MiB alignment for disks with unknown topology, disks with topology information are aligned to optimal (or minimum) I/O size (parted >= 2.1)

- EFI GPT code in the kernel has been updated to works properly with 4KiB sectors (kernel >= 2.6.33)

- mkfs.{ext,xfs,gfs2,ocfs2} have been update to work properly with topology information, mkfs.{ext,xfs} are linked against libblkid for compatibility with old kernel (for stripe chunk size / width)

- Fedora-13/RHEL6 installer uses libparted with 4KiB support

- alignment_offset & 4KiB support is planned for LUKS (cryptsetup)

Quoted 9 lines

Tejun> Unfortunately, the transition to 4 KiB sector size, physical Tejun> only or logical too, is looking fairly ugly. Hopefully, a Tejun> reasonable solution can be reached in not too distant future Tejun> but even with all the software side updated, it looks like Tejun> it's gonna cause significant amount of confusion and frustration.

With regards to XP compatibility I don't think we should go too much out of our way to accommodate it. XP has been disowned by its master and I think virtualization will take care of the rest.

Quoted 2 lines

FWIW, recent fdisk has a command line flag that will enable/disable DOS compatible layout.

yes, util-linux-ng 2.17.1, fdisk -c

Note that non-DOS mode will be default in the next major
util-linux-ng release.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"DLT" == Daniel Taylor <[email protected]> writes:

Quoted 3 lines

Quoted 3 lines

With regards to XP compatibility I don't think we should go too much out of our way to accommodate it. XP has been disowned by its master and I think virtualization will take care of the rest.

Yeah, good point. I'm just a bit worried that it might generate a lot of frustrated bug reports. Well, maybe we should just advise users to install windows first and then install Linux.

On Mon, Mar 08, 2010 at 10:18:27AM -0500, Martin K. Petersen wrote:

Quoted 2 lines

It'd be great if you guys could share what you have been doing to the tooling.

small summary:

- libblkid provides unified API to topology information, it supports:
- ioctls (kernel >= 2.6.32)
- sysfs (kernel >= 2.6.31)
- stripe chunk size and stripe width for DM, MD. LVM and evms on old kernels
- libparted and fdisk are linked against libblkid

- fdisk supports 4KiB logical sector size (util-linux-ng >= 2.15
- fdisk supports 4KiB physical sector size (util-linux-ng >= 2.17)
- fdisk uses 1MiB alignment (or more if optimal I/O size is bigger) and alignment_offset for all partitions in non-DOS mode (util-linux-ng >= 2.17.1)

- parted supports 4KiB physical sector size
- parted uses 1MiB alignment for disks with unknown topology, disks with topology information are aligned to optimal (or minimum) I/O size (parted >= 2.1)

- EFI GPT code in the kernel has been updated to works properly with 4KiB sectors (kernel >= 2.6.33)

- mkfs.{ext,xfs,gfs2,ocfs2} have been update to work properly with topology information, mkfs.{ext,xfs} are linked against libblkid for compatibility with old kernel (for stripe chunk size / width)

- Fedora-13/RHEL6 installer uses libparted with 4KiB support

- alignment_offset & 4KiB support is planned for LUKS (cryptsetup)

Related information, prompted by my recent encounter with a tool that refused to let me use a GPT partition table.

Partition table formats: prefer GUID/GPT:

Having spent more than my share of time looking at partition table formats recently, I am now strongly biased against DOS partition tables, and for GUID/GPT ones. In addition to allowing for >2GiB partition offsets and lengths, GPT tables provide for better protection in case of corruption (checksums, backup table at end of disk) and don't have the anachronistic distinction of primary and extended/logical partitions (all partitions are "primary"). You can even give each partition a name. The only reason to use a DOS partition table on a new installation is if you're stuck with a requirement of using an OS like XP on bare metal.

Please consider encouraging the use of GPT partition tables... or at least do not *dis*courage their use.

I'm Cc:'ing Karel Zak and Jim Meyering who have been doing all the alignment work for fdisk and parted respectively. Karel, Jim: The full writeup is here:

http://ata.wiki.kernel.org/index.php/ATA_4_KiB_sector_issues

It'd be great if you guys could share what you have been doing to the tooling.

Please correct the following bit in C-3:

"A different partition format - GPT[6] - should be used beyond 2^32 sectors, which could harm compatibility with older BIOSs or other operating systems which don't recognize the new format."

BIOS does not care about the partition table format. There might be issues with > 2^32 sectors for BIOSes (e.g. truncating sector counts), but that would be unrelated.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Tejun" == Tejun Heo <[email protected]> writes:

Tejun> Please note that hdparm is misreporting the alignment offset. It Tejun> should be reporting 512 instead of 256 for offset-by-one drives.

Already fixed. Your hdparm must be old.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Tejun" == Tejun Heo <[email protected]> writes:

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Tejun" == Tejun Heo<[email protected]> writes:

Tejun> Yeah, I know Mark fixed it but couldn't find where the tree was. Tejun> SF only had old releases, so...

Tejun> (other stuff replied further down the thread)

Looks like Mark hasn't made an hdparm release since I posted the patch.

http://ata.wiki.kernel.org/index.php/ATA_4_KiB_sector_issues

C-2. Windows XP depends on the traditional partition layout.

Quoted 1 line · Tejun Heo

http://ata.wiki.kernel.org/index.php/ATA_4_KiB_sector_issues

Excellent summary.

Quoted 1 line

C-2. Windows XP depends on the traditional partition layout.

Is this really true? WD ships their EARS drives with an alignment tool that as far as I can understand, moves the partition so it's aligned to 4KiB:

Quoted 4 lines · Mikael Abrahamsson

Quoted 1 line · Tejun Heo

http://ata.wiki.kernel.org/index.php/ATA_4_KiB_sector_issues

Quoted 7 lines

Excellent summary.

Quoted 1 line

C-2. Windows XP depends on the traditional partition layout.

Is this really true? WD ships their EARS drives with an alignment tool that as far as I can understand, moves the partition so it's aligned to 4KiB:

XP SP2 (or later) can boot from any place, including logical partitions (tested that recently). Most important thing is "hidden sectors" (recent chain.c32 can set that automatically through ntldr and/or sethidden options). No idea about pre-SP2 ; Win 2000 will not boot from "misaligned" (with reference to cylinder boundary) partition.

I was thinking about testing XP booting this weekend but really want to avoid it, so thanks a lot for the info. I'll update the doc accordingly but can you please enlighten me on how it works and what's broken in detail? So, XP should be fine with any alignment?

Thanks.

Quoted 8 lines · Tejun Heo

I was thinking about testing XP booting this weekend but really want to avoid it, so thanks a lot for the info.  I'll update the doc accordingly but can you please enlighten me on how it works and what's broken in detail?  So, XP should be fine with any alignment?

Thanks.

Sorry for late reply.

s/sp2/sp3 - although it shouldn't make a difference from sp2 onwards.

Anyway - the tests I did were because of weird laptop, where I shrinked whole win7 stuff and having no primary partitions left to use, I tested my usual windows xp installation I deploy with ntfsclone. Originally that XP were installed from installation disk merged with sp3 (or how it's usually called in windows world - slipstreamed). Of course, windows xp itself will not present any options to install itself into logical partition in the usual way - but during later deployment it's not a problem to put it where one's want.

It's possible that this wouldn't work, if windows were installed first from pre-sp2 media, and then service pack was installed (in such case, ntldr in C:\ is not updated afaik). It's also possible, that "brute-force" copied pre-sp2 or win2k to a partition made with either - a) xp sp2+'s disk manager or b) mkfs.ntfs and with updated most recent ntldr -  would boot as well (the partition requirement is due to potential differences between the code in bootsector, or more precisely - $Boot - first 8KiB of ntfs partition).

Obvious requirements besides the above (ntldr, perhaps $Boot as well) are:

- mentioned "hidden sectors" (must be manually adjusted, recent syslinux's chain.c32 has option to do it automatically)
- adjusted boot.ini (to point to new partition, eventually other windowish stuff as necessary)

As you can see, there're many "if"s and combinations here that I didn't test.

On a related note - ironically, while I had 0 problems making it work through syslinux (both regular chaining and through direct ntldr loading) - I couldn't make win7's bootmgr (bcd, bcdedit ....) do it properly. Oh well.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Please note that hdparm is misreporting the alignment offset. It should be reporting 512 instead of 256 for offset-by-one drives.

On 03/07/10 22:48, Tejun Heo wrote:
..

Quoted 2 lines

Please note that hdparm is misreporting the alignment offset. It should be reporting 512 instead of 256 for offset-by-one drives.

..

That issue was fixed quite a while ago.
Upgrade your elderly copy of hdparm.

Quoted 6 lines · Mark Lord

On 03/07/10 22:48, Tejun Heo wrote:
..

Quoted 2 lines

Please note that hdparm is misreporting the alignment offset. It should be reporting 512 instead of 256 for offset-by-one drives.

..

Quoted 2 lines

That issue was fixed quite a while ago.
Upgrade your elderly copy of hdparm.

Heh heh, *you* were keeping it from me! Anyways, is there hdparm devel tree published somewhere? I wandared the SF page for quite a bit (which for some reason is very difficult to find things in) but I couldn't find one. If it's not, it might be a good idea to put it on SF or git.kernel.org?

Unfortunately, while Windows can assume that newer releases won't share the hard drive with older releases including Windows XP, Linux distros can't do that. There will be many installations where a modern Linux distros share a hard drive with older releases of Windows. At this point, I can't see a silver bullet solution.

Partitioners maybe should only align partitions which will be used by Linux and default to the traditional layout for others while allowing explicit override. I think Windows XP wouldn't have problem with differently aligned partitions as long as it doesn't actually use them but haven't tested it.

Quoted 11 lines · On Monday 08 March 2010 04:48:35 Tejun Heo wrote:

Unfortunately, while Windows can assume that newer releases won't share the hard drive with older releases including Windows XP, Linux distros can't do that. There will be many installations where a modern Linux distros share a hard drive with older releases of Windows. At this point, I can't see a silver bullet solution.

Partitioners maybe should only align partitions which will be used by Linux and default to the traditional layout for others while allowing explicit override. I think Windows XP wouldn't have problem with differently aligned partitions as long as it doesn't actually use them but haven't tested it.

Any idea if XP can cope with partition tables that use a 32-sector, 128-head geometry rather than the default 63-sector, 255-head one? That seems to be what some flash memory cards are using and it would make any cylinder aligned partition also 4096-byte aligned, at the cost of moving the 1024-cylinder boundary from 7.88 GiB to 2 GiB.

Do we know of anything that requires 63s/255h?

Quoted 11 lines · On Monday 08 March 2010 04:48:35 Tejun Heo wrote:

Unfortunately, while Windows can assume that newer releases won't share the hard drive with older releases including Windows XP, Linux distros can't do that.  There will be many installations where a modern Linux distros share a hard drive with older releases of Windows.  At this point, I can't see a silver bullet solution.

Partitioners maybe should only align partitions which will be used by Linux and default to the traditional layout for others while allowing explicit override.  I think Windows XP wouldn't have problem with differently aligned partitions as long as it doesn't actually use them but haven't tested it.

Any idea if XP can cope with partition tables that use a 32-sector, 128-head geometry rather than the default 63-sector, 255-head one? That seems to be what some flash memory cards are using and it would make any cylinder aligned partition also 4096-byte aligned, at the cost of moving the 1024-cylinder boundary from 7.88 GiB to 2 GiB.

Do we know of anything that requires 63s/255h?

Quoted 1 line

Do we know of anything that requires 63s/255h?

63s/255h is more or less "standard" now.

Alignment issues can be solved by picking a good multiple of _heads_ or _cylinders_:

For first partition, pick the start at 8th head:

cyl 0 head 1 sector 1: LBA sector 63) - bad
cyl 0 head 8 sector 1: LBA sector 8*63) - good (4k aligned)

For any other partition, pick start cylinder which is a multiple of 8:

cyl 8*x head 0 sector 1: LBA sector 8*x*255*63 - good (4k aligned)

This will actually work well for *any* geometry, not only for 63s/255h.

63s/255h is more or less "standard" now.

Alignment issues can be solved by picking a good multiple of _heads_ or _cylinders_:

For first partition, pick the start at 8th head:

cyl 0 head 1 sector 1: LBA sector 63) - bad
cyl 0 head 8 sector 1: LBA sector 8*63) - good (4k aligned)

For any other partition, pick start cylinder which is a multiple of 8:

cyl 8*x head 0 sector 1: LBA sector 8*x*255*63 - good (4k aligned)

This will actually work well for *any* geometry, not only for 63s/255h.

Quoted 11 lines · Denys Vlasenko

63s/255h is more or less "standard" now.

Alignment issues can be solved by picking a good multiple of _heads_ or _cylinders_:

For first partition, pick the start at 8th head:

cyl 0 head 1 sector 1: LBA sector 63) - bad
cyl 0 head 8 sector 1: LBA sector 8*63) - good (4k aligned)

Quoted 5 lines

For any other partition, pick start cylinder which is a multiple of 8:

cyl 8*x head 0 sector 1: LBA sector 8*x*255*63 - good (4k aligned)

This will actually work well for *any* geometry, not only for 63s/255h.

Yes, but it does squat for a flash disk that wants, say, 256K alignment.

I just played with ubuntu installation on an usb stick. Yes, it works. Soft of. Write performance is abysmal. I would pay x2 or x3 for the same sized stick if it would perform better.

Quoted 2 lines

Yes, but it does squat for a flash disk that wants, say, 256K alignment.

4K makes sense. 256K not so much.

256K alignment is hard to swallow for a lot of reasons anyway. Unless the filesystem packs small files into blocks a-la reiserfs, 256K block filesystems will be very inefficient for a typical storage scenarios.

Quoted 4 lines

256K alignment is hard to swallow for a lot of reasons anyway. Unless the filesystem packs small files into blocks a-la reiserfs, 256K block filesystems will be very inefficient for a typical storage scenarios.

Noone has talked about using 256K filesystem blocks.

Quoted 18 lines · H. Peter Anvin

Quoted 16 lines · Denys Vlasenko

63s/255h is more or less "standard" now.

Alignment issues can be solved by picking a good multiple of _heads_ or _cylinders_:

For first partition, pick the start at 8th head:

cyl 0 head 1 sector 1: LBA sector 63) - bad
cyl 0 head 8 sector 1: LBA sector 8*63) - good (4k aligned)

For any other partition, pick start cylinder which is a multiple of 8:

cyl 8*x head 0 sector 1: LBA sector 8*x*255*63 - good (4k aligned)

This will actually work well for *any* geometry, not only for 63s/255h.

Quoted 1 line

Yes, but it does squat for a flash disk that wants, say, 256K alignment.

4K makes sense. 256K not so much.

256K alignment is hard to swallow for a lot of reasons anyway. Unless the filesystem packs small files into blocks a-la reiserfs, 256K block filesystems will be very inefficient for a typical storage scenarios.

It looks like flash storage manufacturers just have to bite the bullet and develop smarter algorithms that combine wear leveling, block remapping and such and make their internal preference for huge continuous aligned writes nearly invisible from the outside - just like hard disks which do not expose their zoned recording, variable sector counts etc.

Such algorithms aren't trivial, but they are possible. Whoever will incorporate them in their products, delivers a significantly better user experience.

I just played with ubuntu installation on an usb stick. Yes, it works. Soft of. Write performance is abysmal. I would pay x2 or x3 for the same sized stick if it would perform better.

Quoted 6 lines

Quoted 6 lines

Quoted 5 lines

For any other partition, pick start cylinder which is a multiple of 8:

cyl 8*x head 0 sector 1: LBA sector 8*x*255*63 - good (4k aligned)

This will actually work well for *any* geometry, not only for 63s/255h.

Quoted 8 lines

Quoted 1 line

Yes, but it does squat for a flash disk that wants, say, 256K alignment.

4K makes sense. 256K not so much.

256K alignment is hard to swallow for a lot of reasons anyway. Unless the filesystem packs small files into blocks a-la reiserfs, 256K block filesystems will be very inefficient for a typical storage scenarios.

the thing is, if the OS can learn that it's more efficiant to write in 256K aligned chunks, then it can batch up things so that the drive doesn't have to do a read-modify-write cycle and can instead just replace the entire chunk.

I think Linux already is doing this. The problem is, in many cases OS can't possibly do this, short of using a specially designed filesystem.

If you untar a Linux kernel source tarball on a seriously fragmented ext2 filesystem, there will be a lot of discontiguous and/or misaligned writes smaller than 256K.
Only smart firmware can help in this case.

63s/255h is more or less "standard" now.

Alignment issues can be solved by picking a good multiple of _heads_ or _cylinders_:

partition table which some BIOSs actually try to do. The problem is that to determine the two parameters you need to equations matching

CHSs and LBAs

Hello,

Quoted 4 lines · Denys Vlasenko

63s/255h is more or less "standard" now.

Alignment issues can be solved by picking a good multiple of _heads_ or _cylinders_:

I've got a couple of comments stating that picking a good geometry parameters can resolve the whole issue but I simply fail to see how it could. We can pick any parameter we wish, but there is no reliable way to communicate the custom geometry parameters to others.

Geometry is determined by two parameters sec/trk and heads/cyl. You can punch in those numbers if the BIOS has a menu for it (many don't these days). Or hope that BIOS can somehow figure it out from the partition table which some BIOSs actually try to do. The problem is that to determine the two parameters you need to equations matching CHSs and LBAs and that's available iff the first partition ends before CHS addressing limit according to the custom geometry, which usually is not the case.

So, custom geometry is only useful to trick partitioners which align using cylinders into using better alignments but doesn't help anything for compatibility as no one can determine the used geometry reliably after the partitioning is complete. With compatibility benefit gone, there simply is no reason to stick to the cylinder abstraction at all.

Am I missing something?

So, it is true to say that picking a certain H/S geometry (which is entirely withing the gift of the partitioner) will align msdos label partitions, but will be don't care for all other labels: all other partition labels (like gpt) use block as offset and don't have any truck with the fictitious C/H/S stuff.

The big problem is that 99% of the x86 systems out there still use the ancient msdos label for their boot disks, so aligning H/S going forwards will give us a nice "just works" for x86 boxes.

Most BIOSs these days will simply report the geometry as being 255/63 regardless of the geometry used during partitioning

On 2010/03/16 15:22 (GMT+0900) Tejun Heo composed:

Quoted 2 lines

Most BIOSs these days will simply report the geometry as being 255/63 regardless of the geometry used during partitioning

In my experience this "most" only applies to desktop motherboard BIOS. Most laptop BIOS seem to prefer 240, as do many external USB HD case controllers, and older but not that antique Compaq desktops.

Hello, James.

Quoted 5 lines · James Bottomley

So, it is true to say that picking a certain H/S geometry (which is entirely withing the gift of the partitioner) will align msdos label partitions, but will be don't care for all other labels: all other partition labels (like gpt) use block as offset and don't have any truck with the fictitious C/H/S stuff.

For any modern Linux and Windows, CHS simply doesn't matter. They don't look at it at all.

Quoted 3 lines

The big problem is that 99% of the x86 systems out there still use the ancient msdos label for their boot disks, so aligning H/S going forwards will give us a nice "just works" for x86 boxes.

What I don't get is that how picking up a custom geometry can make things work when there is *no* reliable way to determine which geometry was used during partitioning once the partitioning is complete.

Most BIOSs these days will simply report the geometry as
being 255/63 regardless of the geometry used during partitioning. So, how can using a custom geometry give that nice "just works" for x86 boxes when nobody knows what geometry is in use?

For msdos labels, it's embedded in the label ... for all other labels, it's made up on the spot.

Hello, James.

Quoted 2 lines · James Bottomley

For msdos labels, it's embedded in the label ... for all other labels, it's made up on the spot.

Where in the label?

Quoted 7 lines · Tejun Heo

Hello, James.

Quoted 2 lines · James Bottomley

For msdos labels, it's embedded in the label ... for all other labels, it's made up on the spot.

Where in the label?

No idea ... I only know you can use fdisk expert mode to change the C/H/S layout and the change is preserved across reboots.

Quoted 4 lines

Quoted 2 lines

For msdos labels, it's embedded in the label ... for all other labels, it's made up on the spot.

Where in the label?

No idea ... I only know you can use fdisk expert mode to change the C/H/S layout and the change is preserved across reboots.

e.g. If the first partition begins at CHS 0/32/33 and ends at 12/233/19 and the corresponding LBA addresses are 2048 and 206848, you can solve the equation and determine that the parameters gotta be 63 secs/trk and 255 heads/cyl to make those two pairs of addresses match each other and in fact some BIOSs try to do this depending on configuration (and sometimes falls into infinite loop or causes other boot related problems if the parameters are too uncommon).

Quoted 7 lines · Tejun Heo

e.g. If the first partition begins at CHS 0/32/33 and ends at 12/233/19 and the corresponding LBA addresses are 2048 and 206848, you can solve the equation and determine that the parameters gotta be 63 secs/trk and 255 heads/cyl to make those two pairs of addresses match each other and in fact some BIOSs try to do this depending on configuration (and sometimes falls into infinite loop or causes other boot related problems if the parameters are too uncommon).

for an msdos label, this is illegal, that was Arnd's point. The partitions have to begin and end on cylinder boundaries*. Knowing that, you can deduce the geometry from the last sector entry.

* at least if you want to preserve windows compatibility, which is what most of our partitioning tools seem to do.

Quoted 9 lines · James Bottomley

Quoted 7 lines · Tejun Heo

e.g. If the first partition begins at CHS 0/32/33 and ends at 12/233/19 and the corresponding LBA addresses are 2048 and 206848, you can solve the equation and determine that the parameters gotta be 63 secs/trk and 255 heads/cyl to make those two pairs of addresses match each other and in fact some BIOSs try to do this depending on configuration (and sometimes falls into infinite loop or causes other boot related problems if the parameters are too uncommon).

Quoted 6 lines

for an msdos label, this is illegal, that was Arnd's point. The partitions have to begin and end on cylinder boundaries*. Knowing that, you can deduce the geometry from the last sector entry.

* at least if you want to preserve windows compatibility, which is what most of our partitioning tools seem to do.

Well, the thing is that

* Anything remotely modern (>= XP) doesn't give a hoot about cylinder alignment.

* Anything older (<= 2000) is very likely to get confused with custom geometry starting from the BIOS itself. For those cases, the only thing we can do is aligning partitions to cylinders abiding BIOS supplied geometry parameters which will usually be 255/63.

So, using custom geometry doesn't help compatibility at all.

Quoted 1 line

So, using custom geometry doesn't help compatibility at all.

Our partitioning tool still obey the integral cylinder rule ... we can argue about whether they should, but what we need is a strategy for fixing what is rather than what should be.

Hello,

Quoted 6 lines · James Bottomley

Quoted 2 lines

So, using custom geometry doesn't help compatibility at all.

Our partitioning tool still obey the integral cylinder rule ... we can argue about whether they should, but what we need is a strategy for fixing what is rather than what should be.

The updated ones don't anymore. They just align to 1MiB + whatever the drive requests for offset (the offset-by-one thing). They will basically behave the same as windows vista/7 ones, so it's already fixed. What we can argue is whether adding CHS tricks on top to make those larger alignments somewhat meaningful w/ CHS interpretation too, which I'm objecting on the ground that it doesn't help compatibility at all.

Thanks.

Dropping any mention of CHS seems to be the only sensible thing. Why waste any time to continue some myth about drives that no modern hardware supports (and then have the joy of explaining that to users)?

Talking about it only confuses people and in the worst case, could cause them to misalign their partitions by clinging to these pretend borders :-)

On Wed, 2010-03-17 at 00:20 +0900, Tejun Heo wrote:

Quoted 10 lines

Well, the thing is that

* Anything remotely modern (>= XP) doesn't give a hoot about cylinder alignment.

* Anything older (<= 2000) is very likely to get confused with custom geometry starting from the BIOS itself. For those cases, the only thing we can do is aligning partitions to cylinders abiding BIOS supplied geometry parameters which will usually be 255/63.

Quoted 1 line

So, using custom geometry doesn't help compatibility at all.

Our partitioning tool still obey the integral cylinder rule ... we can argue about whether they should, but what we need is a strategy for fixing what is rather than what should be.

Can't we fix the problem by defaulting to aligning partitions to start on an LBA that is a multiple of 64260 ?

Such partitions will always be 4KiB-aligned, *and* start-of-cylinder aligned (assuming 255/63, as seems to be the norm).

Sure, that reduces your partition granularity to almost-32-MiB, but that's pretty small potatoes these days (and it's only a *default*, so you could always override that if you really cared, and didn't need the compatibility).

Hello,

Quoted 9 lines · Kevin Easton

Can't we fix the problem by defaulting to aligning partitions to start on an LBA that is a multiple of 64260 ?

Such partitions will always be 4KiB-aligned, *and* start-of-cylinder aligned (assuming 255/63, as seems to be the norm).

Sure, that reduces your partition granularity to almost-32-MiB, but that's pretty small potatoes these days (and it's only a *default*, so you could always override that if you really cared, and didn't need the compatibility).

The only thing we can gain by that is possible compatibility w/ very old operating systems (<=w2k, BTW, it would be great if someone can actually test it). Plus, breaking the first cylinder assumption might not be always safe to begin with. I personally don't think it's something worth departing from the behavior most vendors would assume from now on (1MiB alignment). It should be enough and safer to provide a mechanism to choose legacy alignment if someone is trying to put something which is older than a decade there.

Thanks.

Signature · 1 line

tejun

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Tejun" == Tejun Heo <[email protected]> writes:

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Tejun" == Tejun Heo <[email protected]> writes:

Tejun> * Anything remotely modern (>= XP) doesn't give a hoot about
Tejun> cylinder alignment.

Tejun> * Anything older (<= 2000) is very likely to get confused with

Tejun>   custom geometry starting from the BIOS itself.  For those
Tejun>   cases, the only thing we can do is aligning partitions to
Tejun>   cylinders abiding BIOS supplied geometry parameters which will
Tejun>   usually be 255/63.

Tejun> So, using custom geometry doesn't help compatibility at all.

Great reads on this topic. Might be worth linking to:

http://www.win.tue.nl/~aeb/partitions/partition_types.html
http://www.win.tue.nl/~aeb/linux/largedisk.html

Quoted 8 lines · James Bottomley

Quoted 7 lines · Tejun Heo

e.g. If the first partition begins at CHS 0/32/33 and ends at 12/233/19 and the corresponding LBA addresses are 2048 and 206848, you can solve the equation and determine that the parameters gotta be 63 secs/trk and 255 heads/cyl to make those two pairs of addresses match each other and in fact some BIOSs try to do this depending on configuration (and sometimes falls into infinite loop or causes other boot related problems if the parameters are too uncommon).

Quoted 6 lines

for an msdos label, this is illegal, that was Arnd's point. The partitions have to begin and end on cylinder boundaries*. Knowing that, you can deduce the geometry from the last sector entry.

* at least if you want to preserve windows compatibility, which is what most of our partitioning tools seem to do.

Well, the thing is that

* Anything remotely modern (>= XP) doesn't give a hoot about cylinder alignment.

* Anything older (<= 2000) is very likely to get confused with custom geometry starting from the BIOS itself. For those cases, the only thing we can do is aligning partitions to cylinders abiding BIOS supplied geometry parameters which will usually be 255/63.

So, using custom geometry doesn't help compatibility at all.

Hello, James.

Quoted 2 lines · James Bottomley

For msdos labels, it's embedded in the label ... for all other labels, it's made up on the spot.

Where in the label?

The "end of partition" is expected to be at the last head and sector. Of course this heuristic fails if there are more than one primary partition and they have differing last head and sector.

But on most "sanely" partitioned disks they are the same:

Disk /dev/sda: 255 heads, 63 sectors, 36481 cylinders

Nr AF Hd Sec Cyl Hd Sec Cyl Start Size ID

 1 00   1   1    0 254  63  850         63   13671252 0b
 2 80   0   1  851 254  63 1023   13671315  572395950 05
 3 00   0   0    0   0   0    0          0          0 00
 4 00   0   0    0   0   0    0          0          0 00
 5 00   1   1  851 254  63  972         63    1959867 83
 6 00   1   1  973 254  63 1023         63   31246362 83
 7 00 254  63 1023 254  63 1023         63  195318207 83
 8 00 254  63 1023 254  63 1023         63  343871262 83
                   ^^^  ^^

Which suggests another idea how to align a partition: since there is no requirement on the partition *start*, we don't have to start at head1,sector1 or head0,sector1

In the example above, 1st partition might be modified to start at head1,sector2, IOW, LBA 64, thus making it 32k aligned.

As long as partition *ends* adhere to the convention of being exactly at last_head,last_sector, nothing should break.

Quoted 8 lines

The "end of partition" is expected to be at the last head and sector. Of course this heuristic fails if there are more than one primary partition and they have differing last head and sector.

But on most "sanely" partitioned disks they are the same:

Disk /dev/sda: 255 heads, 63 sectors, 36481 cylinders

Quoted 10 lines

Nr AF  Hd Sec  Cyl  Hd Sec  Cyl      Start       Size ID 1 00   1   1    0 254  63  850         63   13671252 0b 2 80   0   1  851 254  63 1023   13671315  572395950 05 3 00   0   0    0   0   0    0          0          0 00 4 00   0   0    0   0   0    0          0          0 00 5 00   1   1  851 254  63  972         63    1959867 83 6 00   1   1  973 254  63 1023         63   31246362 83 7 00 254  63 1023 254  63 1023         63  195318207 83 8 00 254  63 1023 254  63 1023         63  343871262 83 ^^^  ^^

C/H/S of 1023/254/63 is a special marker indicating the value there is out-of-range.

Quoted 3 lines

Which suggests another idea how to align a partition: since there is no requirement on the partition *start*, we don't have to start at head1,sector1 or head0,sector1

We don't have to align to cylinders either.

Quoted 5 lines

In the example above, 1st partition might be modified to start at head1,sector2, IOW, LBA 64, thus making it 32k aligned.

As long as partition *ends* adhere to the convention of being exactly at last_head,last_sector, nothing should break.

That has almost nothing to do with compatibility.  Just let the cylinder alignment go.

Quoted 2 lines

C/H/S of 1023/254/63 is a special marker indicating the value there is out-of-range.

You misunderstood my ^^^ markers. I was trying to highlight the whole columns of "end head" and "end sector", not the last partition's 1023/254/63 values.

In the partition table like shown above it is obvious that geometry is 255/63.

Quoted 1 line

We don't have to align to cylinders either.

If neither the start nor the end is aligned to cylinder's end and disk has just one partition and it's bigger than 8G, there is not way to determine geometry.

If everybody adopts the convention of ending the partitions at the cylinder end, geometry can be trivially determined by looking at partition end values. Sans "no of cylinders" value, which can be easily determined by other means.

Because the msdos label can only partition in units of cylinders. If you're using an msdos label, picking the right H/S gets you alignment.

The big problem is that 99% of the x86 systems out there still use the ancient msdos label for their boot disks, so aligning H/S going forwards will give us a nice "just works" for x86 boxes.