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

From: Ric Wheeler <rwheeler@redhat.com>
To: Dave Chinner <david@fromorbit.com>, Eric Sandeen <sandeen@sandeen.net>
Cc: Christoph Hellwig <hch@infradead.org>,
	Eric Sandeen <sandeen@redhat.com>, xfs-oss <xfs@oss.sgi.com>
Subject: Re: [PATCH RFC] xfs: set block device logical sector size on xfs_buftarg
Date: Fri, 22 Nov 2013 09:13:56 -0500	[thread overview]
Message-ID: <528F66A4.7060200@redhat.com> (raw)
In-Reply-To: <20131114210156.GP6188@dastard>

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

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs