Re: [GIT PULL] Btrfs updates for 5.8, part 2
On Mon, Jun 15, 2020 at 2:29 PM Christoph Hellwig 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 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_vwx3we...@mail.gmail.com/#t -- Filipe David Manana, “Whether you think you can, or you think you can't — you're right.”
Re: [GIT PULL] Btrfs updates for 5.8, part 2
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 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.
Re: [GIT PULL] Btrfs updates for 5.8, part 2
On Sun, Jun 14, 2020 at 09:50:17AM -0700, Linus Torvalds wrote: > On Sun, Jun 14, 2020 at 4:56 AM David Sterba 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.
Re: [GIT PULL] Btrfs updates for 5.8, part 2
On Sun, Jun 14, 2020 at 09:50:17AM -0700, Linus Torvalds wrote: > On Sun, Jun 14, 2020 at 4:56 AM David Sterba 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.
Re: [GIT PULL] Btrfs updates for 5.8, part 2
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
Re: [GIT PULL] Btrfs updates for 5.8, part 2
On Sun, Jun 14, 2020 at 4:56 AM David Sterba 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
[GIT PULL] Btrfs updates for 5.8, part 2
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(-)
Re: [GIT PULL] Btrfs updates for 5.8
The pull request you sent on Mon, 1 Jun 2020 14:37:21 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-5.8-tag has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/f3cdc8ae116e27d84e1f33c7a2995960cebb73ac Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
[GIT PULL] Btrfs updates for 5.8
Hi, please pull the following updates to btrfs. Thanks. Highlights: - speedup dead root detection during orphan cleanup, eg. when there are many deleted subvolumes waiting to be cleaned, the trees are now looked up in radix tree instead of a O(N^2) search - snapshot creation with inherited qgroup will mark the qgroup inconsistent, requires a rescan - send will emit file capabilities after chown, this produces a stream that does not need postprocessing to set the capabilities again - direct io ported to iomap infrastructure, cleaned up and simplified code, notably removing last use of struct buffer_head in btrfs code Core changes: - factor out backreference iteration, to be used by ordinary backreferences and relocation code - improved global block reserve utilization * better logic to serialize requests * increased maximum available for unlink * improved handling on large pages (64K) - direct io cleanups and fixes * simplify layering, where cloned bios were unnecessarily created for some cases * error handling fixes (submit, endio) * remove repair worker thread, used to avoid deadlocks during repair - refactored block group reading code, preparatory work for new type of block group storage that should improve mount time on large filesystems Cleanups: - cleaned up (and slightly sped up) set/get helpers for metadata data structure members - root bit REF_COWS got renamed to SHAREABLE to reflect the that the blocks of the tree get shared either among subvolumes or with the relocation trees Fixes: - when subvolume deletion fails due to ENOSPC, the filesystem is not turned read-only - device scan deals with devices from other filesystems that changed ownership due to overwrite (mkfs) - fix a race between scrub and block group removal/allocation - fix long standing bug of a runaway balance operation, printing the same line to the syslog, caused by a stale status bit on a reloc tree that prevented progress - fix corrupt log due to concurrent fsync of inodes with shared extents - fix space underflow for NODATACOW and buffered writes when it for some reason needs to fallback to COW mode The following changes since commit 9cb1fd0efd195590b828b9b865421ad345a4a145: Linux 5.7-rc7 (2020-05-24 15:32:54 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-5.8-tag for you to fetch changes up to 2166e5edce9ac1edf3b113d6091ef72fcac2d6c4: btrfs: fix space_info bytes_may_use underflow during space cache writeout (2020-05-28 14:01:53 +0200) Anand Jain (5): btrfs: drop useless goto in open_fs_devices btrfs: include non-missing as a qualifier for the latest_bdev btrfs: free alien device after device add btrfs: drop stale reference to volume_mutex btrfs: unexport btrfs_compress_set_level() Christoph Hellwig (1): btrfs: split btrfs_direct_IO to read and write part David Sterba (26): btrfs: don't force read-only after error in drop snapshot btrfs: sort error decoder entries btrfs: add more codes to decoder table btrfs: remove more obsolete v0 extent ref declarations btrfs: use the token::eb for all set/get helpers btrfs: drop eb parameter from set/get token helpers btrfs: don't use set/get token for single assignment in overwrite_item btrfs: don't use set/get token in leaf_space_used btrfs: preset set/get token with first page and drop condition btrfs: add separate bounds checker for set/get helpers btrfs: speed up btrfs_get_##bits helpers btrfs: speed up btrfs_get_token_##bits helpers btrfs: speed up btrfs_set_##bits helpers btrfs: speed up btrfs_set_token_##bits helpers btrfs: speed up and simplify generic_bin_search btrfs: remove unused map_private_extent_buffer btrfs: constify extent_buffer in the API functions btrfs: drop unnecessary offset_in_page in extent buffer helpers btrfs: optimize split page read in btrfs_get_##bits btrfs: optimize split page read in btrfs_get_token_##bits btrfs: optimize split page write in btrfs_set_##bits btrfs: optimize split page write in btrfs_set_token_##bits btrfs: update documentation of set/get helpers btrfs: simplify root lookup by id btrfs: open code read_fs_root btrfs: simplify iget helpers Eric Biggers (1): btrfs: use crypto_shash_digest() instead of open coding Filipe Manana (16): btrfs: remove pointless assertion on reclaim_size counter btrfs: simplify error handling of clean_pinned_extents() btrfs: remove useless check for copy_items() return value btrfs: fix a race between scrub and block group removal/allocation btrfs: rename member 'trimming' of block group to a more generic name
