From: Anand Jain <anand.jain@oracle.com>
To: dsterba@suse.cz
Cc: linux-btrfs@vger.kernel.org,
"Guilherme G . Piccoli" <gpiccoli@igalia.com>,
David Sterba <dsterba@suse.com>,
Filipe Manana <fdmanana@kernel.org>
Subject: Re: [PATCH 0/2] btrfs: support cloned-device mount capability
Date: Tue, 3 Oct 2023 09:13:20 +0800 [thread overview]
Message-ID: <c96b0c14-9624-c080-3290-214824df1bea@oracle.com> (raw)
In-Reply-To: <20231002130040.GO13697@twin.jikos.cz>
On 02/10/2023 21:00, David Sterba wrote:
> On Thu, Sep 28, 2023 at 09:09:45AM +0800, Anand Jain wrote:
>> Guilherme's previous work [1] aimed at the mounting of cloned devices
>> using a superblock flag SINGLE_DEV during mkfs.
>> [1] https://lore.kernel.org/linux-btrfs/20230831001544.3379273-1-gpiccoli@igalia.com/
>>
>> Building upon this work, here is in-memory only approach. As it mounts
>> we determine if the same fsid is already mounted if then we generate a
>> random temp fsid which shall be used the mount, in-memory only not
>> written to the disk. We distinguish device by devt.
>>
>> Mount option / superblock flag:
>> -------------------------------
>> These patches show we don't have to limit the single-device / temp_fsid
>> capability with a mount option or a superblock flag from the btrfs
>> internals pov. However, if necessary from the user's perspective,
>> we can add them later on top of this patch. I've prepared a mount option
>> -o temp_fsid patch, but I'm not included at this time. As most of the
>> tests was without it.
>>
>> Compatible with other features that may be affected:
>> ----------------------------------------------------
>> Multi device:
>> A btrfs filesytem on a single device can be copied using dd and
>> mounted simlutaneously. However, a multi device btrfs copied using
>> dd and trying to mount simlutaneously is forced to fail:
>>
>> mount: /btrfs1: mount(2) system call failed: File exists.
>>
>> Send and receive:
>> Quick tests shows send and receive between two single devices with
>> the same fsid mounted on the _same_ host works!.
>
> Does it depend if the filesystem remains mounted for the whole
> time? So if there's an unmount, mount again with a temp-fsid, will
> the receive still work?
Yes! Send-receive works even after a mount-recycle with the new
temp-fsid, as shown below.
Cc-ing Filipe for any comments or send-receive scenario that might fail,
if any?
---------------------
mkfs a test device whose uuid and fsid will be duplicated
$ mkfs.btrfs -fq /dev/sdc1
$ blkid /dev/sdc1
/dev/sdc1: UUID="99821bd4-322c-4a71-a88d-b9bb3e56223b"
UUID_SUB="1881db58-1c2f-4639-bf87-5c0af24433d6" TYPE="btrfs"
PARTUUID="a0de6580-01"
$ mount /dev/sdc1 /btrfs
using the above uuid and fsid mkfs two more scratch device
$ mkfs.btrfs -fq -U 99821bd4-322c-4a71-a88d-b9bb3e56223b -P
1881db58-1c2f-4639-bf87-5c0af24433d6 /dev/sdc2
$ mkfs.btrfs -fq -U 99821bd4-322c-4a71-a88d-b9bb3e56223b -P
1881db58-1c2f-4639-bf87-5c0af24433d6 /dev/sdc3
mount scratch devices; it will mount using temp-fsid
$ mount /dev/sdc2 /btrfs1
$ mount /dev/sdc3 /btrfs2
$ btrfs filesystem show -m
Label: none uuid: 99821bd4-322c-4a71-a88d-b9bb3e56223b
Total devices 1 FS bytes used 144.00KiB
devid 1 size 10.00GiB used 536.00MiB path /dev/sdc1
Label: none uuid: d041437c-d12e-427c-b0c2-e2591b069feb
Total devices 1 FS bytes used 144.00KiB
devid 1 size 10.00GiB used 536.00MiB path /dev/sdc2
Label: none uuid: 91c7978f-342f-43d5-a88a-d131dd34962e
Total devices 1 FS bytes used 144.00KiB
devid 1 size 10.00GiB used 536.00MiB path /dev/sdc3
create first data and send-receive
$ xfs_io -f -c 'pwrite -S 0x16 0 9000' /btrfs1/foo
$ btrfs su snap -r /btrfs1 /btrfs1/snap1
Create a readonly snapshot of '/btrfs1' in '/btrfs1/snap1'
$ btrfs send /btrfs1/snap1 | btrfs receive /btrfs2
At subvol /btrfs1/snap1
At subvol snap1
$ sha256sum /btrfs1/foo
e856cd48942364eed9a205c64aa5e737ab52a73ba2800b07de9d4c331f88cb5b
/btrfs1/foo
$ sha256sum /btrfs2/snap1/foo
e856cd48942364eed9a205c64aa5e737ab52a73ba2800b07de9d4c331f88cb5b
/btrfs2/snap1/foo
mount recycle so that we have new temp-fsid
$ umount /btrfs2
$ umount /btrfs1
$ mount /dev/sdc2 /btrfs1
$ mount /dev/sdc3 /btrfs2
$ btrfs filesystem show -m
Label: none uuid: 99821bd4-322c-4a71-a88d-b9bb3e56223b
Total devices 1 FS bytes used 144.00KiB
devid 1 size 10.00GiB used 536.00MiB path /dev/sdc1
Label: none uuid: 34549411-c9cf-4118-8e42-58dbfd5c4964
Total devices 1 FS bytes used 172.00KiB
devid 1 size 10.00GiB used 536.00MiB path /dev/sdc2
Label: none uuid: a9ec3b45-f809-49ad-bcb2-bd4b65b130d8
Total devices 1 FS bytes used 172.00KiB
devid 1 size 10.00GiB used 536.00MiB path /dev/sdc3
modify foo and send-receive
$ xfs_io -f -c 'pwrite -S 0xdb 0 9000' /btrfs1/foo
$ btrfs su snap -r /btrfs1 /btrfs1/snap2
Create a readonly snapshot of '/btrfs1' in '/btrfs1/snap2'
$ btrfs send -p /btrfs1/snap1 /btrfs1/snap2 | btrfs receive /btrfs2
At snapshot snap2
At subvol /btrfs1/snap2
$ sha256sum /btrfs1/foo
5a97ea23517b5f1255161345715f5831b59cbcd62f1fd57e40329980faa7dbd8
/btrfs1/foo
$ sha256sum /btrfs2/snap2/foo
5a97ea23517b5f1255161345715f5831b59cbcd62f1fd57e40329980faa7dbd8
/btrfs2/snap2/foo
-----------------------------------------------------
>
>> (Also, the receive-mnt can receive from multiple senders as long as
>> conflits are managed externally. ;-).)
>>
I mean multiple senders on temp-fsid mount as long as they have the same
superblock::fsid.
Thanks, Anand
>> Replace:
>> Works fine.
>>
>> btrfs-progs:
>> ------------
>> btrfs-progs needs to be updated to support the commands such as
>>
>> btrfs filesystem show
>>
>> when devices are not mounted. So the device list is not based on
>> the fisd any more.
>>
>> Testing:
>> -------
>> This patch has been under testing for some time. The challenge is to get
>> the fstests to test this reasonably well.
>>
>> As of now, this patch runs fine on a large set of fstests test cases
>> using a custom-built mkfs.btrfs with the -U option and a new -P option
>> to copy the device FSID and UUID from the TEST_DEV to the SCRATCH_DEV
>> at the scratch_mkfs time. For example:
>>
>> Config file:
>>
>> config_fsid=$(btrfs in dump-super $TEST_DEV | grep -E ^fsid | \
>> awk '{print $2}')
>> config_uuid=$(btrfs in dump-super $TEST_DEV | \
>> grep -E ^dev_item.uuid | awk '{print $2}')
>> MKFS_OPTIONS="-U $config_fsid -P $config_uuid"
>>
>> This configuration option ensures that both TEST_DEV and SCRATCH_DEV will
>> have the same FSID and device UUID while still applying test-specific
>> scratch mkfs options.
>>
>> Mkfs.btrfs:
>> -----------
>> mkfs.btrfs needs to be updated to support the -P option for testing only.
>>
>> btrfs-progs: allow duplicate fsid for single device
>> btrfs-progs: add mkfs -P option for dev_uuid
>>
>> Anand Jain (2):
>> btrfs: add helper function find_fsid_by_disk
>> btrfs: support cloned-device mount capability
>
> Added to misc-next, thanks.
next prev parent reply other threads:[~2023-10-03 1:14 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-28 1:09 [PATCH 0/2] btrfs: support cloned-device mount capability Anand Jain
2023-09-28 1:09 ` [PATCH 1/2] btrfs: add helper function find_fsid_by_disk Anand Jain
2023-10-02 11:45 ` David Sterba
2023-10-03 0:57 ` Anand Jain
2023-09-28 1:09 ` [PATCH 2/2] btrfs: support cloned-device mount capability Anand Jain
2023-10-02 12:57 ` David Sterba
2023-10-02 22:41 ` Anand Jain
2023-10-02 12:52 ` [PATCH 0/2] " Anand Jain
2023-10-02 13:00 ` David Sterba
2023-10-03 1:13 ` Anand Jain [this message]
2023-10-06 7:42 ` Guilherme G. Piccoli
2023-10-07 8:01 ` Anand Jain
2023-10-18 14:15 ` Guilherme G. Piccoli
2023-10-19 2:13 ` Anand Jain
2023-10-19 8:15 ` Guilherme G. Piccoli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c96b0c14-9624-c080-3290-214824df1bea@oracle.com \
--to=anand.jain@oracle.com \
--cc=dsterba@suse.com \
--cc=dsterba@suse.cz \
--cc=fdmanana@kernel.org \
--cc=gpiccoli@igalia.com \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).