On 11/14/13, 12:49 AM, Dave Chinner wrote:
> On Wed, Nov 13, 2013 at 06:35:05PM -0600, Eric Sandeen wrote:
>> On 11/13/13, 12:25 PM, Eric Sandeen wrote:
>>> Pure RFC; this might be crazy. Here's the problem I'm trying to solve:
>>>
>>> Today, mkfs.xfs will select a 4k sector size for a 4k physical / 512 logical
>>> drive. (that change was done by me). The thought was that it'd be an
>>> efficiency gain to not make the drive do the (possible) RMW cycles on
>>> 512-byte log IO, primarily.
>>>
>>> However, now this restricts all DIO to 4k alignment, not the otherwise-
>>> possible 512.
>>
>> So, backing up... ;)
>>
>> XFS isn't doing anything wrong here. It can make sector sizes as it pleases,
>> and apps had darned well better accommodate its whims if they do direct IO.
>>
>> But some apps don't. And users are sad and confused, and grow to dislike
>> XFS, because it all worked just fine on that other filesystem, so screw you
>> XFS, and your flux capacitor drives with your power-fail interrupts!
>
> Funny how it's always XFS is at fault, when the same problem with 4k
> sectors will occur on ext4, for example....
Yep on a non-existent hard 4k disk, ext4 would have the same problem.
Meanwhile in the world of actual hardware, ext4 is fine. (there's no
similar sector-size switch for ext4).
Again; I'm NOT saying xfs is doing anything wrong, or is at fault.
We can be right all the way to the grave, if apps never get fixed,
and users have a choice of fs.
...
>> We could even ensure that XFS_IOC_DIOINFO offers up "4k" as the answer
>> to miniosz, so that apps which bother to ask get the optimal answer.
>
> Funnily enough, it does:
>
> da.d_mem = da.d_miniosz = 1 << target->bt_sshift;
...
Of course it does today; I was talking about whether we could report this
but still allow 512 under the covers.
>> Or, we could stop setting 4k sectors for AF drives.
>
> And just take the RMW penalty?
that, and the bonus of existing applications continuing to function.
>> Or we could just carry on, and keep telling users that it's their fault,
>> their app's fault, etc...
>
> ... and getting the problems fixed so they go away forever.
... or not. *cough*64 bit inodes*cough*
>> (I'm sympathetic to pushing the envelope and dragging apps into the 21st
>> century, but it's s double edged sword).
>
> Yes, it is, but if we don't take a stand and say "we, as an
> ecosystem, need to support 4k sectors *everywhere*", then we are
> going to have such problems *forever*. This isn't purely an XFS
> problem - this is something that the entire storage stack needs to
> support, from the hardware at the very bottom to the applications at
> the very top.
>
> XFS is stuck in the middle, where we cop it from both
> the hardware side ("why don't you support our hardware efficiently
> yet?") and from the application side when we do ("4k sectors break
> our assumptions!"). It's a no win situation for us no matter what we
> do, and history has shown that when we don't take a strong
> leadership position the problems don't get solved.
>
> So, let's take the initiative and make sure that everyone knows how
> to deal with these problems and get them fixed in the right places.
> I don't want to be spending the next 10 years complaining about a
> lack of 4k sector support in qemu. It's too much like the inode64
> saga over all over again.
which, TBH, has still never been fully addressed.
> Let's face it, it wouldn't be right if XFS wasn't fighting some
> battle to drag Linux kicking and screaming into the present...
Well. With my distro hat on I might have to be pragmatic, and keep
things working that are required to work.
Upstream, sure, we can keep beating users with a stick until they
force their app writers to make things work for them again. ;)
(Again, though, as middle ground - if there were a way for XFS to do
all internal IO efficiently as 4k-aligned, but allow applications
to do 512 emulation, that would be, IMHO, a great thing. I'm not
yet sure what it would take.)
-Eric
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
