| Message ID | cover.1670451918.git.josef@toxicpanda.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | extent buffer dirty cleanups | expand |
On Wed, Dec 07, 2022 at 05:28:03PM -0500, Josef Bacik wrote: > Hello, > > While sync'ing ctree.c to btrfs-progs I noticed we have some oddities when it > comes to how we deal with the extent buffer being dirty. We have > btrfs_clean_tree_block, which is sort of meant to be run against extent buffers > we've modified in this transaction. However we have some other places where > we've open coded the same work without the generation check. This makes it kind > of confusing, and is inconsistent with how we deal with the > fs_info->dirty_metadata_bytes. > > So clean this stuff up so we have one helper we use for setting the extent > buffer dirty (btrfs_mark_buffer_dirty) and one for clearing dirty > (btrfs_clear_buffer_dirty). This makes everything more consistent and clean > across the board. I've additionally cleaned up a random writeback thing we had > in tree-log that I noticed while doing these cleanups. Thanks, > > Josef > > Josef Bacik (8): > btrfs: always lock the block before calling btrfs_clean_tree_block > btrfs: do not check header generation in btrfs_clean_tree_block > btrfs: do not set the header generation before btrfs_clean_tree_block > btrfs: replace clearing extent buffer dirty bit with btrfs_clean_block > btrfs: do not increment dirty_metadata_bytes in set_btree_ioerr > btrfs: rename btrfs_clean_tree_block => btrfs_clear_buffer_dirty > btrfs: combine btrfs_clear_buffer_dirty and clear_extent_buffer_dirty > btrfs: remove btrfs_wait_tree_block_writeback Added to misc-next, thanks.
Hi, > Hello, > > While sync'ing ctree.c to btrfs-progs I noticed we have some oddities when it > comes to how we deal with the extent buffer being dirty. We have > btrfs_clean_tree_block, which is sort of meant to be run against extent buffers > we've modified in this transaction. However we have some other places where > we've open coded the same work without the generation check. This makes it kind > of confusing, and is inconsistent with how we deal with the > fs_info->dirty_metadata_bytes. > > So clean this stuff up so we have one helper we use for setting the extent > buffer dirty (btrfs_mark_buffer_dirty) and one for clearing dirty > (btrfs_clear_buffer_dirty). This makes everything more consistent and clean > across the board. I've additionally cleaned up a random writeback thing we had > in tree-log that I noticed while doing these cleanups. Thanks, > > Josef > > Josef Bacik (8): > btrfs: always lock the block before calling btrfs_clean_tree_block > btrfs: do not check header generation in btrfs_clean_tree_block > btrfs: do not set the header generation before btrfs_clean_tree_block > btrfs: replace clearing extent buffer dirty bit with btrfs_clean_block > btrfs: do not increment dirty_metadata_bytes in set_btree_ioerr > btrfs: rename btrfs_clean_tree_block => btrfs_clear_buffer_dirty > btrfs: combine btrfs_clear_buffer_dirty and clear_extent_buffer_dirty > btrfs: remove btrfs_wait_tree_block_writeback xfstests result with/without these patches. with the patches [1-8] btrfs/066 btrfs/072 btrfs/074 failed with the patches [1-5] btrfs/066 btrfs/072 btrfs/074 failed without the patches OK. no failure. Best Regards Wang Yugui (wangyugui@e16-tech.com) 2022/12/15 > fs/btrfs/ctree.c | 16 +++++++-------- > fs/btrfs/disk-io.c | 25 +++++------------------- > fs/btrfs/disk-io.h | 2 +- > fs/btrfs/extent-tree.c | 12 ++++-------- > fs/btrfs/extent_io.c | 18 +++++++++-------- > fs/btrfs/extent_io.h | 2 +- > fs/btrfs/free-space-tree.c | 2 +- > fs/btrfs/ioctl.c | 2 +- > fs/btrfs/qgroup.c | 2 +- > fs/btrfs/tree-log.c | 40 ++++++++++++++------------------------ > 10 files changed, 47 insertions(+), 74 deletions(-) > > -- > 2.26.3