On 11/22/13, 8:13 AM, Ric Wheeler wrote:
> I think you do that by using SCSI debug to get a 4K sector drive -
> that is how we tested for RHEL6 for example. Layering on restrictions
> to hardware in the file system seems a bit harsh.
> The QEMU crowd will be working to get better support for 4K drives in
> the future, but I think that we are effectively going to cause a huge
> field issue here since these 512/4K drives are extremely common..
> Given the SCSI debug method for this, does that mean you retract your
> objections and will support Eric's patch :) ?
FWIW, my patch is a disaster, but I'll work on something along those
lines that's not a disaster, so we can discuss it properly. ;)
To make this go, I think we need to add a structure member to the
xfs_buftarg which describes the logical sector size, and use that
to enforce minimum IO sizes. The current sector size fields can
remain in place for the mkfs-specified, presumably physical sector
Then, since the sector sizes in the sb, mp, and buftarg have been
disassociated a bit, I'll need to audit things like the sub-block
zeroing paths so that we DTRT on a sub-block DIO.
At that point, the "sector size" semantics in the mkfs.xfs manpage
get a little weird; if we specify a sector size of 4k, how can
we do sub-sector IOs?
What the mkfs option really means at that point is that the specified
size is the minimum size and alignment which will be generated from
within the filesystem for metadata; we can make it clear that the
underlying logical sector size is still the constraint for userspace
I'm not quite sure what the XFS_IOC_DIOINFO ioctl should advertise,
at that point.
Anyway, that's about where I'm at in my brain with all this, will
try to get something that actually works relatively soon.