Re: Comment on ATA 4 KiB sector issues

Re: Comment on ATA 4 KiB sector issues

[Tomasz Palac]

On Tue, 9 Mar 2010, Tejun Heo wrote:

> Hello,
>
> I prefer if linux-ide@vger.kernel.org is cc'd so if you're okay with
> it, please add cc when you reply.

OK.

> On 03/08/2010 05:53 PM, Tomasz Palac wrote:
>> I've read your document on ATA 4 KiB sector issues and I have a simple
>> solution for partitioning 4 KiB physical/512 B logical drives with no
>> offset.
>>
>> I use geometry of 64 heads and 32 (logical) sectors. This way cylinder
>> is exactly 1 MiB. First partition starts at 2nd cylinder and is aligned
>> at 1 MiB. Other primary partition are aligned at 1 MiB too. If one of
>> them is extended partition, then logical partitions within it will be
>> aligned at 16 KiB (32 logical sectors).
>>
>> This scheme can be applied to SSDs, with the exception of logical
>> partitions (16 KiB alignment will probably not be enough).
>>
>> I don't know if older Windows will accept such partitioning scheme, but
>> if it uses CHS values, then it should.
>
> Well, the thing is that there is no way to reliably communicate those
> geometry values and 255*63 is hardcoded everywhere.  The only way you
> can deduce the geometry is by solving equation with the CHS address
> and LBA in the partition table but for that to work the first
> partition should end before CHS limit.

This limit is 8 GiB and there is no problem with first partitions 
extending beyond that. This is because such partitions are described in 
partition table as ending at 1023/255/63 (or something like that). Real 
size of partition is specified by LBA values.

> Using custom geometry is a good way to trick a partitioner which
> partitions based on CHS alignment to align to larger units but it
> isn't meaningful outside of that.  If CHS dosen't follow 255*63, a lot
> of code (firmware, BIOS, boot loader, OS...) will just assume CHS is
> incorrect.

As of firmware, Large Disk Howto states that a lot of SCSI host adapters 
are using 64/32 geometry (at least for disks smaller than 8 GiB). If BIOS 
supports EDD (INT13h Extensions), then disk geometry is irrelevant. If 
not, then geometry can be read from partition table. The only problem with 
64/32 geometry is 1 GiB (as opposed to 8 GiB) limit for boot partition 
(without using EDD). The same applies to boot loaders. Modern OSes don't 
use CHS.

-- 
Tomasz Palac, AGH University of Science and Technology

Re: Comment on ATA 4 KiB sector issues

[Tejun Heo]

Hello,

On 03/09/2010 06:22 PM, Tomasz Palac wrote:
>> Using custom geometry is a good way to trick a partitioner which
>> partitions based on CHS alignment to align to larger units but it
>> isn't meaningful outside of that.  If CHS dosen't follow 255*63, a lot
>> of code (firmware, BIOS, boot loader, OS...) will just assume CHS is
>> incorrect.
> 
> As of firmware, Large Disk Howto states that a lot of SCSI host
> adapters are using 64/32 geometry (at least for disks smaller than 8
> GiB).  If BIOS supports EDD (INT13h Extensions), then disk geometry
> is irrelevant.

Yes, the geometry is basically arbitrary values which can be queried
using a BIOS call and the reason why SCSI hosts can choose them is
they implement BIOS extensions themselves.

> If not, then geometry can be read from partition table.

>From where?

> The only problem with 64/32 geometry is 1 GiB (as opposed to 8 GiB)
> limit for boot partition (without using EDD). The same applies to
> boot loaders. Modern OSes don't use CHS.

For modern OSes, geometry doesn't matter at all.  Older ones are the
ones having problems (I've been corrected: XP seems okay while 2000
depends on CHS).

Thanks.

-- 
tejun

Re: Comment on ATA 4 KiB sector issues

[Tomasz Palac]

On Wed, 10 Mar 2010, Tejun Heo wrote:

> Yes, the geometry is basically arbitrary values which can be queried
> using a BIOS call and the reason why SCSI hosts can choose them is
> they implement BIOS extensions themselves.

I mentioned SCSI host adapters to show that 64/32 geometry is no problem 
for Linux (and other OS-es). Really is 255/63 hardcoded in many places?

>> If not, then geometry can be read from partition table.
>
> From where?

>From the ending CHS values of partition if it ends at cylinder boundary.
How do you calculate geometry from newer Windows partition tables (cases 
W-1, W-2 and W-3)?

> For modern OSes, geometry doesn't matter at all.  Older ones are the
> ones having problems (I've been corrected: XP seems okay while 2000
> depends on CHS).

You are proposing "doing what Windows is doing". This way:

1. Partitions are aligned at 1 MiB (which is very good).
2. Geometry is "standard", i.e. 255/63 (which is good).
3. Partitions don't start and end at cylinder boundary (which is not so
    good).

With 64/32 you can have:

1. Partitions aligned at 1 MiB.
2. Geometry is not standard, but is widely used (SCSI disks, USB flash
    disks).
3. Partitions start and end at cylinder boundary.

-- 
Tomasz Palac, AGH University of Science and Technology

Re: Comment on ATA 4 KiB sector issues

[Tejun Heo]

Hello,

On 03/10/2010 05:15 PM, Tomasz Palac wrote:
>> Yes, the geometry is basically arbitrary values which can be queried
>> using a BIOS call and the reason why SCSI hosts can choose them is
>> they implement BIOS extensions themselves.
> 
> I mentioned SCSI host adapters to show that 64/32 geometry is no problem
> for Linux (and other OS-es). Really is 255/63 hardcoded in many places?

For starters, on some mobos I have, I can't change the reported
geometry.

>>> If not, then geometry can be read from partition table.
>>
>> From where?
> 
>> From the ending CHS values of partition if it ends at cylinder boundary.
> How do you calculate geometry from newer Windows partition tables (cases
> W-1, W-2 and W-3)?

By solving the equations matching CHSs and LBAs.  It only works if the
first partition ends before the CHS address limit (2 variables to
solve for so we need 2 different equations).

>> For modern OSes, geometry doesn't matter at all.  Older ones are the
>> ones having problems (I've been corrected: XP seems okay while 2000
>> depends on CHS).
> 
> You are proposing "doing what Windows is doing". This way:
> 
> 1. Partitions are aligned at 1 MiB (which is very good).
> 2. Geometry is "standard", i.e. 255/63 (which is good).
> 3. Partitions don't start and end at cylinder boundary (which is not so
>    good).
> 
> With 64/32 you can have:
> 
> 1. Partitions aligned at 1 MiB.
> 2. Geometry is not standard, but is widely used (SCSI disks, USB flash
>    disks).
> 3. Partitions start and end at cylinder boundary.

2 and 3 are meaningful iff the users agree on using that specific
geometry.  W/o any reliable way to communicate that custom geometry to
other users of the partition table, 2 and 3 virtually don't exist.
Partitioner partitions according to 64/32, BIOS reports 63/255.  It's
just broken.

We can feed 64/32 or whatever geometry to partitioners to trick them
into beliving certain geometry so that the end result is aligned in
certain way but that works only if the users of the partition table
don't care about CHS addresses in the partition table at all (most
modern ones don't).  The only reason we're talking about geometry is
for compatibility w/ older operating systems.  So, at this point,
diddling with geometry just doesn't make any sense at all.

Thanks.

-- 
tejun

Re: Comment on ATA 4 KiB sector issues

[Tomasz Palac]

On Wed, 10 Mar 2010, Tejun Heo wrote:

>> How do you calculate geometry from newer Windows partition tables (cases
>> W-1, W-2 and W-3)?
>
> By solving the equations matching CHSs and LBAs.  It only works if the
> first partition ends before the CHS address limit (2 variables to
> solve for so we need 2 different equations).

Thanks for explanation. So with 64/32 geometry this should work for 
partitions smaller than 1 GiB. With 255/63 geometry this limit is 8 GiB 
and there are partitions bigger than that. Maybe for bigger partitions 
BIOSes use ending CHS?

> The only reason we're talking about geometry is for compatibility w/ 
> older operating systems.  So, at this point, diddling with geometry just 
> doesn't make any sense at all.

If we "do as Windows do" and make partitions aligned at 1 MiB but not 
aligned at cylinder boundary, then there is no way to boot Windows 2000 or 
older OS. If we use 64/32 geometry, there is a chance (maybe small) that 
BIOS will calculate or assume correct CHS values and older OS can boot. 
And this geometry cannot hurt newer OSes.

-- 
Tomasz Palac, AGH University of Science and Technology

Re: Comment on ATA 4 KiB sector issues

[Tejun Heo]

Hello,

On 03/10/2010 06:40 PM, Tomasz Palac wrote:
>> By solving the equations matching CHSs and LBAs.  It only works if the
>> first partition ends before the CHS address limit (2 variables to
>> solve for so we need 2 different equations).
> 
> Thanks for explanation. So with 64/32 geometry this should work for
> partitions smaller than 1 GiB. With 255/63 geometry this limit is 8 GiB
> and there are partitions bigger than that. Maybe for bigger partitions
> BIOSes use ending CHS?

I suspect more BIOSs would just assume 255/63 regardless of the
partition layout these days.  For bigger partitions, the ending CHS is
just a marker saying that it's off the limit and there really isn't
any information to calculate from.

>> The only reason we're talking about geometry is for compatibility w/
>> older operating systems.  So, at this point, diddling with geometry
>> just doesn't make any sense at all.
> 
> If we "do as Windows do" and make partitions aligned at 1 MiB but not
> aligned at cylinder boundary, then there is no way to boot Windows 2000
> or older OS. If we use 64/32 geometry, there is a chance (maybe small)
> that BIOS will calculate or assume correct CHS values and older OS can
> boot. And this geometry cannot hurt newer OSes.

Going forward, I think it would be simply better and less painful to
stick to the simpler scheme which is also employed by Windows and
allowing some way to use the old alignment for certain partitions for
those few special cases where really old OSs need to be used.  The
benefit of 64/32 or any other custom geometry seems marginal at best
and mostly imaginary to me.

Thanks.

-- 
tejun