From: Anand Jain <anand.jain@oracle.com>
To: linux-btrfs@vger.kernel.org
Cc: Anand Jain <anand.jain@oracle.com>,
"Guilherme G . Piccoli" <gpiccoli@igalia.com>,
David Sterba <dsterba@suse.com>
Subject: [PATCH 0/2] btrfs: support cloned-device mount capability
Date: Thu, 28 Sep 2023 09:09:45 +0800 [thread overview]
Message-ID: <cover.1695826320.git.anand.jain@oracle.com> (raw)
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!.
(Also, the receive-mnt can receive from multiple senders as long as
conflits are managed externally. ;-).)
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
fs/btrfs/disk-io.c | 3 +-
fs/btrfs/volumes.c | 75 +++++++++++++++++++++++++++++++++++++++++++---
fs/btrfs/volumes.h | 2 ++
3 files changed, 75 insertions(+), 5 deletions(-)
--
2.38.1
next reply other threads:[~2023-09-28 1:10 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-28 1:09 Anand Jain [this message]
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
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=cover.1695826320.git.anand.jain@oracle.com \
--to=anand.jain@oracle.com \
--cc=dsterba@suse.com \
--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).