[PATCH RFC] xfs: set block device logical sector size on xfs_buftarg

[Ric Wheeler]

On 11/14/2013 04:01 PM, Dave Chinner wrote:
> On Thu, Nov 14, 2013 at 08:56:04AM -0600, Eric Sandeen wrote:
>> On 11/14/13, 7:37 AM, Christoph Hellwig wrote:
>>> On Thu, Nov 14, 2013 at 08:26:58AM +1100, Dave Chinner wrote:
>>>> Seems like that's the avenue for improvement here to me. i.e. expose
>>>> the correct values to the guest so it's mkfs does the right thing.
>>>> Or, alternatively, make qemu buffer non-aligned/sized IOs itself
>>>> internally.
>>> I've implemented the support to expose these to the guest in qemu
>>> years ago.  But the problem remains that this is information which
>>> needs to be attached to the image, which can't really work with raw
>>> images, and no one has bother to implement the support to store it
>>> for say qcow2.
>>>
>> Ok but once again - this is not a guest mkfs issue.  The reported
>> problem is that the guest cannot _boot_ in cache=none mode because
>> the bios attempts a 512-byte DIO.
> A different viewpoint: How can we make sure real 4k sector hardware
> works with Linux when it comes along if we can't emulate it via
> qemu + virtualisation?
>
> People often use qemu + virutalisation as a method of testing code
> for hardware they don't have access to, and this just seems like
> another of those things that we should have working in this
> environment long before real hardware comes along and requires it...
>
> Cheers,
>
> Dave.

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

Regards,

Ric