Re: [Qemu-devel] [PATCH RFC] Advertise IDE physical block size as 4K

Re: [Qemu-devel] [PATCH RFC] Advertise IDE physical block size as 4K

[Christoph Hellwig]

On Tue, Dec 29, 2009 at 02:39:38PM +0100, Luca Tettamanti wrote:
> Linux tools put the first partition at sector 63 (512-byte) to retain
> compatibility with Windows;

Well, some of them, and depending on the exact disks.  It's all rather
complicated.

> > It has been discussed for hardware disk design with 4k sectors, and
> > somehow there were plans to map sectors so that the Linux partition
> > scheme results in nicely aligned filesystem blocks
> 
> Ugh, I hope you're wrong ;-) AFAICS remapping will lead only to
> headaches... Linux does not have any problem with aligned partitions.

Linux doesn't care.  As doesn't windows.  But performance on mis-aligned
partitions will suck badly - both on 4k sector drives, SSDs or probably
various copy on write layers in virtualization once you hit the worst
case.  Fortunately the block topology information present in recent
ATA and SCSI standards allows the storage hardware to tell about the
required alignment, and Linux now has a topology API to expose it, which
is used by the most recent versions of the partitioning tools and
filesystem creation tools.

Re: [Qemu-devel] [PATCH RFC] Advertise IDE physical block size as 4K

[Christoph Hellwig]

On Tue, Dec 29, 2009 at 12:07:58PM +0200, Avi Kivity wrote:
> Guests use this number as a hint for alignment and I/O request sizes.  Given
> that modern disks have 4K block sizes, and cached file-backed images also
> have 4K block sizes, this hint can improve guest performance.
> 
> We probably need to make this configurable depending on machine type.  It
> should be the default for -M 0.13 only as it can affect guest code paths.

The information is correct per the ATA spec, but:

 (a) as mentioned above it should not be used for old machine types
 (b) we need to sort out passing through the first block alignment bits
     that are also in IDENTIFY word 106 if using a raw block device
     underneat
 (b) probably need to adjust the physical blocks size depending on the
     underlying storage topology.

I have a patch in my queue for a while now dealing with (b) and parts of
(c), but it's been preempted by more urgent work.