public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH RFC 00/10] btrfs-progs: mkfs: add --seed option to sprout a seed device at mkfs time
Date: Wed, 20 Apr 2022 08:19:49 +0800	[thread overview]
Message-ID: <cover.1650413308.git.wqu@suse.com> (raw)

This branch can be fetched from github:
https://github.com/adam900710/btrfs-progs/tree/mkfs_seed

Which contains all the fixes submitted to the mailing list, along with
the patchset.


Sometime ago I purposed to make seed sprout done in user space, now here
comes the working prototype.

To support such seemingly easy feature, it's way more complex than I
thought:

- Delay chunk/dev extent items insertion
- Add a way to track above delayed items for chunk allocation
  This allows btrfs to allocate multiple chunks in the same transaction,
  and should reduce possible false ENOSPC bugs in progs.

  Although further cleanup is not in the patchset.

- Implement quirks for sprout
  * Update device item for seed device
  * Force metadata/system chunk allocation during sprout
  * Relocate system chunks to avoid seed device in sys_chunk_array
  * Remove empty seed chunks

  Those quirks all have specific helpers implemented in mkfs/sprout.c.

  Personally speaking we can enhance kernel/progs to handle seed devices
  in sys_chunk_array, but since it's the long existing behavior, I
  choose to keep the same behavior to avoid compatibility problems.

With all these solved, I intentionally add some limitation on the new
--seed option:

- Ignore -m/-d profiles specification
  Just like kernel, we inherit the old profile from the seed device.
  So if those options are set, we just output a warning and continue.

- Limit the source seed device to be a single device fs
  In fact, I don't even think multi-device seed fs is sane.
  Like a two-disks RAID1 seed fs, adding a device will force we allocate
  SINGLE chunk, as we have no way to directly add two device in one go.

- Only accept one sprout device
  This is completely an artificial limit. Just because I don't see much
  usefulness to have an completely empty device added.

- Reject --rootdir
  This is a preventive behavior, as --rootdir can easily conflicts with
  the existing context from seed device.

Currently there is only one usecase that can not be replace by the user
space sprout:

   Read-only mount of the seed device and sprout without unmount.

Which can be useful for certain liveCD usage.

However even liveCD is no longer providing old-school RO fs as root fs.
Nowadays most liveCD uses memory block device, combined with overlayfs
to provide a RW root fs.

Thus if we go that way, the user space sprout can still be a very useful 
feature.

Although the feature works fine locally, and I have already done the
patch split to contain the changeset, the main point for the patchset is
still to evaluate whether this is a solid idea.

Thus any feedback on the feature (including rejection) is welcomed.

Qu Wenruo (10):
  btrfs-progs: refactor find_free_dev_extent_start() for later expansion
  btrfs-progs: delay chunk and device extent items insertion
  btrfs-progs: mkfs: introduce helper to set seed flag
  btrfs-progs: mkfs: avoid error out if some trees exist
  btrfs-progs: extract btrfs_fs_devices structure allocation into a
    helper
  btrfs-progs: mkfs/sprout: add a helper to update generation for seed
    device
  btrfs-progs: mkfs/sprout: introduce helper to force allocating a chunk
  btrfs-progs: mkfs/sprout: introduce a helper to relocate system chunks
  btrfs-progs: mkfs/sprout: introduce a helper to remove empty system
    chunks from seed device
  btrfs-progs: mkfs: add support for seed sprout

 Documentation/mkfs.btrfs.rst |  13 +
 Makefile                     |   2 +-
 kernel-shared/ctree.h        |   2 +
 kernel-shared/extent-tree.c  |  17 +-
 kernel-shared/transaction.c  |  77 ++++++
 kernel-shared/transaction.h  |  12 +
 kernel-shared/volumes.c      | 280 ++++++++++++---------
 kernel-shared/volumes.h      |  12 +
 mkfs/main.c                  | 133 +++++++++-
 mkfs/sprout.c                | 465 +++++++++++++++++++++++++++++++++++
 mkfs/sprout.h                |  13 +
 11 files changed, 900 insertions(+), 126 deletions(-)
 create mode 100644 mkfs/sprout.c
 create mode 100644 mkfs/sprout.h

-- 
2.35.1


             reply	other threads:[~2022-04-20  0:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-20  0:19 Qu Wenruo [this message]
2022-04-20  0:19 ` [PATCH RFC 01/10] btrfs-progs: refactor find_free_dev_extent_start() for later expansion Qu Wenruo
2022-04-20  0:19 ` [PATCH RFC 02/10] btrfs-progs: delay chunk and device extent items insertion Qu Wenruo
2022-04-20  0:19 ` [PATCH RFC 03/10] btrfs-progs: mkfs: introduce helper to set seed flag Qu Wenruo
2022-04-20  0:19 ` [PATCH RFC 04/10] btrfs-progs: mkfs: avoid error out if some trees exist Qu Wenruo
2022-04-20  0:19 ` [PATCH RFC 05/10] btrfs-progs: extract btrfs_fs_devices structure allocation into a helper Qu Wenruo
2022-04-20  0:19 ` [PATCH RFC 06/10] btrfs-progs: mkfs/sprout: add a helper to update generation for seed device Qu Wenruo
2022-04-20  0:19 ` [PATCH RFC 07/10] btrfs-progs: mkfs/sprout: introduce helper to force allocating a chunk Qu Wenruo
2022-04-20  0:19 ` [PATCH RFC 08/10] btrfs-progs: mkfs/sprout: introduce a helper to relocate system chunks Qu Wenruo
2022-04-20  0:19 ` [PATCH RFC 09/10] btrfs-progs: mkfs/sprout: introduce a helper to remove empty system chunks from seed device Qu Wenruo
2022-04-20  0:19 ` [PATCH RFC 10/10] btrfs-progs: mkfs: add support for seed sprout Qu Wenruo

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.1650413308.git.wqu@suse.com \
    --to=wqu@suse.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