linux-kernel - Re: ATA 4 KiB sector issues.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1268720060.21384.10.camel@mulgrave.site>
Date:	Mon, 15 Mar 2010 23:14:20 -0700
From:	James Bottomley <James.Bottomley@...e.de>
To:	Tejun Heo <tj@...nel.org>
Cc:	Denys Vlasenko <vda.linux@...glemail.com>,
	Arnd Bergmann <arnd@...db.de>,
	"linux-ide@...r.kernel.org" <linux-ide@...r.kernel.org>,
	lkml <linux-kernel@...r.kernel.org>,
	Daniel Taylor <Daniel.Taylor@....com>,
	Jeff Garzik <jeff@...zik.org>, Mark Lord <kernel@...savvy.com>,
	tytso@....edu, "H. Peter Anvin" <hpa@...or.com>,
	hirofumi@...l.parknet.co.jp,
	Andrew Morton <akpm@...ux-foundation.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>, irtiger@...il.com,
	Matthew Wilcox <matthew@....cx>, aschnell@...e.de,
	knikanth@...e.de, jdelvare@...e.de
Subject: Re: ATA 4 KiB sector issues.

On Tue, 2010-03-16 at 11:30 +0900, Tejun Heo wrote:
> Hello,
> 
> On 03/10/2010 06:14 PM, Denys Vlasenko wrote:
> > 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?

Sort of.  As you say, C/H/S doesn't exist for any modern disk.  However,
the msdos label, for reasons lost in the mists of time, uses cylinders
as the units of partition boundaries, so we have to invent a bogus C/H/S
geometry for that partition label.  Because of the problems with picking
C/H/S, most boot loaders take care to ensure that BIOS never cares about
it either (by using the block offset I/O routines), so for most linux
bootloaders, the BIOS problems with C/H/S is a red herring.

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.

James


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