From: Ric Wheeler <ricwheeler@gmail.com>
To: xfs@oss.sgi.com
Subject: Re: [PATCH RFC] xfs: set block device logical sector size on xfs_buftarg
Date: Thu, 14 Nov 2013 22:09:45 +0900 [thread overview]
Message-ID: <5284CB99.6030702@gmail.com> (raw)
In-Reply-To: <20131114064932.GO6188@dastard>
(large snip)
On 11/14/2013 03:49 PM, Dave Chinner wrote:
>> (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.
>
> 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...
>
> Cheers,
>
> Dave.
I would agree that we should not to hit our 4K sector support, have we reached
out the the KVM/QEMU people to see if we can get them to fix this on their side?
Ric
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-11-14 13:10 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-13 18:25 [PATCH RFC] xfs: set block device logical sector size on xfs_buftarg Eric Sandeen
2013-11-13 18:56 ` Christoph Hellwig
2013-11-13 19:08 ` Eric Sandeen
2013-11-13 21:26 ` Dave Chinner
2013-11-13 21:32 ` Eric Sandeen
2013-11-13 22:10 ` Dave Chinner
2013-11-13 22:18 ` Eric Sandeen
2013-11-14 0:34 ` Dave Chinner
2013-11-14 13:37 ` Christoph Hellwig
2013-11-14 14:56 ` Eric Sandeen
2013-11-14 21:01 ` Dave Chinner
2013-11-22 14:13 ` Ric Wheeler
2013-11-22 14:20 ` Christoph Hellwig
2013-11-22 14:26 ` Ric Wheeler
2013-11-22 14:57 ` Eric Sandeen
2013-11-14 0:35 ` Eric Sandeen
2013-11-14 6:49 ` Dave Chinner
2013-11-14 13:09 ` Ric Wheeler [this message]
2013-11-14 15:03 ` Eric Sandeen
2013-11-14 15:18 ` Eric Sandeen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5284CB99.6030702@gmail.com \
--to=ricwheeler@gmail.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox