[PATCH 1/2][SRU][Disco] UBUNTU: SAUCE: shiftfs: add O_DIRECT support

[Christian Brauner]

On Fri, Jul 19, 2019 at 03:02:21PM -0500, Seth Forshee wrote:
> On Fri, Jul 19, 2019 at 05:50:46PM +0200, Christian Brauner wrote:
> > BugLink: https://bugs.launchpad.net/bugs/1837223
> > 
> > This enabled O_DIRECT support for shiftfs if the underlay supports it.
> > 
> > Currently shiftfs does not handle O_DIRECT if the underlay supports it.
> > This is blocking dqlite - an essential part of LXD - from profiting from
> > the performance benefits of O_DIRECT on suitable filesystems when used
> > with async io such as aio or io_uring.
> > Overlayfs cannot support this directly since the upper filesystem in
> > overlay can be any filesystem. So if the upper filesystem does not
> > support O_DIRECT but the lower filesystem does you're out of luck.
> > Shiftfs does not suffer from the same problem since there is not concept
> > of an upper filesystem in the same way that overlayfs has it.
> > Essentially, shiftfs is a transparent shim relaying everything to the
> > underlay while overlayfs' upper layer is not (completely).
> 
> I get concerned any time shiftfs just copies up some non-trivial data
> from the lower filesystem, that shiftfs is going to get bypassed and
> some important metadata will not get propoerly updated in shiftfs. The
> question that immediately comes to mind in this case is whether i_size
> in the shiftfs indoe gets updated following an O_DIRECT write, and I
> suspect tha there are other similar cases to worry about. Have you

I'm not following, what are "other similar cases to worry about" and are
those already exposed?

Re: i_size for O_DIRECT
I have not seen prior art for filesystems that use iomap for O_DIRECT
that would fiddle with i_size so I didn't want to get into that game.
That is to say, shiftfs only supports O_DIRECT if the underlying
filesystem is iomap based. This was the same approach that overlayfs
wanted to use.

Christian