Hi,
this reverts the direct io port to iomap infrastructure of btrfs merged
in the first pull request. We found problems in invalidate page that
don't seem to be fixable as regressions or without changing iomap code
that would not affect other filesystems.
There are 4 patches reverted in total, but 3 of them are followup
cleanups needed to revert a43a67a2d715540c13 cleanly. The result is the
buffer head based implementation of direct io.
There's one trivial conflict that git does not auto-resolve, in the
address space operations readpages has been replaced by readahead and
this change is in the context of the direct io callback diff.
Reverts are not great, but under current circumstances I don't see
better options. Please pull, thanks.
----------------------------------------------------------------
The following changes since commit 2166e5edce9ac1edf3b113d6091ef72fcac2d6c4:
btrfs: fix space_info bytes_may_use underflow during space cache writeout (2020-05-28 14:01:53 +0200)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-5.8-part2-tag
for you to fetch changes up to 55e20bd12a56e06c38b953177bb162cbbaa96004:
Revert "btrfs: switch to iomap_dio_rw() for dio" (2020-06-14 01:19:02 +0200)
----------------------------------------------------------------
David Sterba (4):
Revert "btrfs: split btrfs_direct_IO to read and write part"
Revert "btrfs: remove BTRFS_INODE_READDIO_NEED_LOCK"
Revert "fs: remove dio_end_io()"
Revert "btrfs: switch to iomap_dio_rw() for dio"
fs/btrfs/Kconfig | 1 -
fs/btrfs/btrfs_inode.h | 18 +++
fs/btrfs/ctree.h | 4 -
fs/btrfs/file.c | 97 +------------
fs/btrfs/inode.c | 379 +++++++++++++++++++++++++++++++------------------
fs/direct-io.c | 19 +++
include/linux/fs.h | 2 +
7 files changed, 286 insertions(+), 234 deletions(-)
On Sun, Jun 14, 2020 at 4:56 AM David Sterba <[email protected]> wrote:
>
> Reverts are not great, but under current circumstances I don't see
> better options.
Pulled. Are people discussing how to make iomap work for everybody?
It's a bit sad if we can't have the major filesystems move away from
the old buffer head interfaces to a common more modern one..
Linus
The pull request you sent on Sun, 14 Jun 2020 13:56:05 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-5.8-part2-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/9d645db853a4cd1b7077931491d0055602d3d420
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
On Sun, Jun 14, 2020 at 09:50:17AM -0700, Linus Torvalds wrote:
> On Sun, Jun 14, 2020 at 4:56 AM David Sterba <[email protected]> wrote:
> >
> > Reverts are not great, but under current circumstances I don't see
> > better options.
>
> Pulled. Are people discussing how to make iomap work for everybody?
> It's a bit sad if we can't have the major filesystems move away from
> the old buffer head interfaces to a common more modern one..
As far as I know it basically works. There are a few issues which I
think we could actually trivially fix for 5.8.
On Sun, Jun 14, 2020 at 09:50:17AM -0700, Linus Torvalds wrote:
> On Sun, Jun 14, 2020 at 4:56 AM David Sterba <[email protected]> wrote:
> >
> > Reverts are not great, but under current circumstances I don't see
> > better options.
>
> Pulled. Are people discussing how to make iomap work for everybody?
> It's a bit sad if we can't have the major filesystems move away from
> the old buffer head interfaces to a common more modern one..
Yes, it's fixable and we definitely want to move to iomap. The direct to
buffered fallback would fix one of the problems, but this would also
mean that xfs would start doing that. Such change should be treated more
like a feature development than a bugfix, imposed by another filesystem,
and xfs people rightfully complained.
It's quite possible that there's a better way to fix it on the iomap API
level but I haven't looked into that yet. We get support from iomap
people to add what we need for btrfs, so it's just a matter of time and
testing.
On Mon, Jun 15, 2020 at 02:57:01PM +0200, David Sterba wrote:
> On Sun, Jun 14, 2020 at 09:50:17AM -0700, Linus Torvalds wrote:
> > On Sun, Jun 14, 2020 at 4:56 AM David Sterba <[email protected]> wrote:
> > >
> > > Reverts are not great, but under current circumstances I don't see
> > > better options.
> >
> > Pulled. Are people discussing how to make iomap work for everybody?
> > It's a bit sad if we can't have the major filesystems move away from
> > the old buffer head interfaces to a common more modern one..
>
> Yes, it's fixable and we definitely want to move to iomap. The direct to
> buffered fallback would fix one of the problems, but this would also
> mean that xfs would start doing that. Such change should be treated more
> like a feature development than a bugfix, imposed by another filesystem,
> and xfs people rightfully complained.
We can trivially key that off a flag at least for 5.8. I suspect the
fallback actually is the right thing for XFS in the long run for that
particular case.
On Mon, Jun 15, 2020 at 2:29 PM Christoph Hellwig <[email protected]> wrote:
>
> On Mon, Jun 15, 2020 at 02:57:01PM +0200, David Sterba wrote:
> > On Sun, Jun 14, 2020 at 09:50:17AM -0700, Linus Torvalds wrote:
> > > On Sun, Jun 14, 2020 at 4:56 AM David Sterba <[email protected]> wrote:
> > > >
> > > > Reverts are not great, but under current circumstances I don't see
> > > > better options.
> > >
> > > Pulled. Are people discussing how to make iomap work for everybody?
> > > It's a bit sad if we can't have the major filesystems move away from
> > > the old buffer head interfaces to a common more modern one..
> >
> > Yes, it's fixable and we definitely want to move to iomap. The direct to
> > buffered fallback would fix one of the problems, but this would also
> > mean that xfs would start doing that. Such change should be treated more
> > like a feature development than a bugfix, imposed by another filesystem,
> > and xfs people rightfully complained.
>
> We can trivially key that off a flag at least for 5.8. I suspect the
> fallback actually is the right thing for XFS in the long run for that
> particular case.
We also have another regression (a deadlock) [1] introduced by the patchset.
I haven't looked into detail to figure out if it can be completely
solved in btrfs or if it would need a change on iomap.
Goldwyn was looking into it, but I don't know if he made any progress.
[1] https://lore.kernel.org/linux-btrfs/CAL3q7H4F9iQJy3tgwZrWOKwenAnnn7oSthQZUMEJ_vWx3WE3WQ@mail.gmail.com/#t
--
Filipe David Manana,
“Whether you think you can, or you think you can't — you're right.”