btrfs-progs: docs: add extra notes for 6.17 and newer kernels for Seeding

[BEHAVIOR CHANGE]
In the incoming v6.17 kernel release, due to the changes in commit
40426dd147ff ("btrfs: use the super_block as holder when mounting file
systems"), we can no longer mount a seed device through both sprouted
fs and the seed device.

E.g.

  # mkfs.btrfs -f /dev/test/scratch1
  # mount /dev/test/scratch1 /mnt/btrfs
  # xfs_io -f -c "pwrite 0 16m" /mnt/btrfs/foobar
  # umount /mnt/btrfs
  # btrfstune -S1 /dev/test/scratch1
  # mount /dev/test/scratch1 /mnt/btrfs
  # btrfs device add /dev/test/scratch2 /mnt/btrfs

  Now the sprouted fs is mount, but if one wants to mount the seed
  device, it will fail:

  # mount /dev/test/scratch1  /mnt/btrfs/
  mount: /mnt/btrfs: /dev/mapper/test-scratch1 already mounted or mount point busy.
         dmesg(1) may have more information after failed mount system call.

  The only new dmesg is:

  BTRFS error: failed to open device for path /dev/mapper/test-scratch1 with flags 0x23: -16

[CAUSE]
After that kernel commit, each block device will have its own unique
holder (super block).

This super block block device holder is critical to pass device events
like freeze/thaw/missing to each filesystem.

And after the seed device is sprouted, the holder for the seed device is
the super block of the sprouted fs.

But if some one else tries to mount the seed device again, it will be a
new super block as the holder passed into bdev_file_open_by_path().

Since the seed device already has a different holder, this new
bdev_file_open_by_path() will fail with -EBUSY.

[ENHANCEMENT]
This is a kernel behavior change, but considering the benefit (proper
bdev events passing into the fs) I'd say the old behavior is more like a
hack or a coincidence, other than a properly designed behavior.

So update the documentation to make it more explicit.

Reviewed-by: Boris Burkov <boris@bur.io>
Signed-off-by: Qu Wenruo <wqu@suse.com>

Author: adam900710

Documentation/ch-seeding-device.rst

@@ -19,6 +19,16 @@ read-only, it can be used to seed multiple filesystems from one device at the
 same time. The UUID that is normally attached to a device is automatically
 changed to a random UUID on each mount.
 
+.. note::
+
+        Before v6.17 kernel, a seed device could have been mounted
+        independently along with sprouted filesystems.
+	But since 6.17 kernel, a seed device can only be mounted either through
+	a sprouted filesystem, or the seed device itself, not both at the same time.
+
+	This is to ensure a block device to have only a single filesystem bound
+	to it, so that runtime device missing events can be properly handled.
+
 Once the seeding device is mounted, it needs the writable device. After adding
 it, unmounting and mounting with :command:`umount /path; mount /dev/writable
 /path` or remounting read-write with :command:`remount -o remount,rw` makes the