btrfs: add comments on the extra btrfs specific subpage bitmaps

Unlike the iomap_folio_state structure, the btrfs_subpage structure has a
lot of extra sub-bitmaps, namely:

- writeback sub-bitmap
- locked sub-bitmap
  iomap_folio_state uses an atomic for writeback tracking, while it has
  no per-block locked tracking.

  This is because iomap always locks a single folio, and submits dirty
  blocks with that folio locked.

  But btrfs has async delalloc ranges (for compression), which are queued
  with their range locked, until the compression is done, then marks the
  involved range writeback and unlocked.

  This means a range can be unlocked and marked writeback at seemingly
  random timing, thus it needs the extra tracking.

  This needs a huge rework on the lifespan of async delalloc range
  before we can remove/simplify these two sub-bitmaps.

- ordered sub-bitmap
- checked sub-bitmap
  These are for COW-fixup, but as I mentioned in the past, the COW-fixup
  is not really needed anymore and these two flags are already marked
  deprecated, and will be removed in the near future after comprehensive
  tests.

Add related comments to indicate we're actively trying to align the
sub-bitmaps to the iomap ones.

Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>

diff --git a/fs/btrfs/subpage.h b/fs/btrfs/subpage.h
index 3042c5ea840aec7fbe57f2a63fa876fa8eebc7af..52546e0e97ce44a1657f0fc9847e0361b6445c32 100644 (file)
--- a/fs/btrfs/subpage.h
+++ b/fs/btrfs/subpage.h
@@ -33,8 +33,22 @@ enum {
        btrfs_bitmap_nr_uptodate = 0,
        btrfs_bitmap_nr_dirty,
        btrfs_bitmap_nr_writeback,
+       /*
+        * The ordered and checked flags are for COW fixup, already marked
+        * deprecated, and will be removed eventually.
+        */
        btrfs_bitmap_nr_ordered,
        btrfs_bitmap_nr_checked,
+
+       /*
+        * The locked bit is for async delalloc range (compression), currently
+        * async extent is queued with the range locked, until the compression
+        * is done.
+        * So an async extent can unlock the range at any random timing.
+        *
+        * This will need a rework on the async extent lifespan (mark writeback
+        * and do compression) before deprecating this flag.
+        */
        btrfs_bitmap_nr_locked,
        btrfs_bitmap_nr_max
 };