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]
Date:	Sun, 07 Mar 2010 23:53:12 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	James Bottomley <James.Bottomley@...e.de>
CC:	Tejun Heo <tj@...nel.org>,
	"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, 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, mkp@....net
Subject: Re: ATA 4 KiB sector issues.

On 03/07/2010 11:00 PM, James Bottomley wrote:
> 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.
>

I would very much like a reference for a platform which has firmware 
which can successfully boot from 4K-logical media.  It would be very 
useful for bootloader testing.

Aligning partitions is something we should have done long ago.  It 
affects RAID and many flash drives just as much or more than 4K-sectored 
disks.

Legacy BIOS doesn't care at all how the disk is partitioned, so as long 
as the BIOS can read the disk at all the rest is up to the bootloader. 
Of course, since there hasn't been the opportunity to test, bootloaders 
generally don't handle it correctly (early versions of Syslinux 
supported any sector size, but that bitrotted, and for the lack of 
testing I eventually ended up hard-coding the number.  Now I'd like to 
get it working properly.)

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