On 11/22/13, 8:13 AM, Ric Wheeler wrote: <snip> > 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 size. 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 DIO. 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. -Eric > Regards, > > Ric > _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
