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: <4B9F2388.2030803@kernel.org>
Date:	Tue, 16 Mar 2010 15:22:00 +0900
From:	Tejun Heo <tj@...nel.org>
To:	James Bottomley <James.Bottomley@...e.de>
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.

Hello, James.

On 03/16/2010 03:14 PM, James Bottomley wrote:
> 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.

> 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?

Thanks.

-- 
tejun
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ