linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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).