c8h4/btrfs-progs
1
0
Fork 0
Code Issues Pull requests Actions Packages Projects Releases Wiki Activity

btrfs-progs: docs: discourage seeding remount workflow

Browse source 
The remount workflow could cause some problems so make a note about it.
Recommend the umount/mount step by default. A seeding device used for
e.g. a root filesystem that gets updated and has snapshots is a real
world example where the space consumed by unreclaimed deleted snapshots
would hurt.

Pull-request: #462
Author: Boris Burkov <boris@bur.io>
Signed-off-by: David Sterba <dsterba@suse.com>
This commit is contained in:
Boris Burkov 2022-04-14 10:30:30 -07:00 committed by David Sterba
parent 1e18750288
commit aa49b7cfbb
1 changed files with 19 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

25
Documentation/ch-seeding-device.rst
View file

@ -18,11 +18,18 @@ same time. The UUID that is normally attached to a device is automatically
changed to a random UUID on each mount.
Once the seeding device is mounted, it needs the writable device. After adding
it, something like :command:`remount -o remount,rw /path` makes the filesystem at
*/path* ready for use. The simplest use case is to throw away all changes by
unmounting the filesystem when convenient.
it, unmounting and mounting with :command:`umount /path; mount /dev/writable
/path` or remounting read-write with :command:`remount -o remount,rw` makes the
filesystem at :file:`/path` ready for use.
Alternatively, deleting the seeding device from the filesystem can turn it into
.. note::
There is a known bug with using remount to make the mount writeable:
remount will leave the filesystem in a state where it is unable to
clean deleted snapshots, so it will leak space until it is unmounted
and mounted properly.
Furthermore, deleting the seeding device from the filesystem can turn it into
a normal filesystem, provided that the writable device can also contain all the
data from the seeding device.
@ -45,7 +52,8 @@ Example how to create and use one seeding device:
# mount /dev/sda /mnt/mnt1
# btrfs device add /dev/sdb /mnt/mnt1
# mount -o remount,rw /mnt/mnt1
# umount /mnt/mnt1
# mount /dev/sdb /mnt/mnt1
... /mnt/mnt1 is now writable
Now */mnt/mnt1* can be used normally. The device */dev/sda* can be mounted
@ -55,7 +63,8 @@ again with a another writable device:
# mount /dev/sda /mnt/mnt2
# btrfs device add /dev/sdc /mnt/mnt2
# mount -o remount,rw /mnt/mnt2
# umount /mnt/mnt2
# mount /dev/sdc /mnt/mnt2
... /mnt/mnt2 is now writable
The writable device (*/dev/sdb*) can be decoupled from the seeding device and
@ -76,6 +85,10 @@ A few things to note:
* block group profiles *single* and *dup* support the use cases above
* the label is copied from the seeding device and can be changed by :command:`btrfs filesystem label`
* each new mount of the seeding device gets a new random UUID
* :command:`umount /path; mount /dev/writable /path` can be replaced with
:command:`mount -o remount,rw /path`
but it won't reclaim space of deleted subvolumes until the seeding device
is mounted read-write again before making it seeding again
Chained seeding devices
^^^^^^^^^^^^^^^^^^^^^^^