All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Teigland <teigland@redhat.com>
To: Glass Su <glass.su@suse.com>
Cc: lvm-devel@lists.linux.dev, zkabelac@redhat.com,
	Heming Zhao <heming.zhao@suse.com>
Subject: Re: Request for comments about support btrfs in lvresize
Date: Mon, 10 Mar 2025 11:24:54 -0500	[thread overview]
Message-ID: <Z88QTwcyqqn-faz_@redhat.com> (raw)
In-Reply-To: <D418C150-C1F3-4067-9B72-65C4542DF19F@suse.com>

On Mon, Mar 10, 2025 at 04:35:54PM +0800, Glass Su wrote:
> Hi
>  I am drafting patches for btrfs support in lvresize command. All things went smoothly until I realized
> multi-devices btrfs handling is a little complicated.

btrfs using multiple devices sounds like an alternative to putting btrfs
on lvm, so is this actually done?

> For one device btrfs, fslastblock * fsblocksize/FSSIZE is the correct value like ext* and xfs
> But for multi-devices btrfs, the two values are whole fs size. The used size of device can be
> known by btrfs-progs or superblock read and parse.

These values are used to calculate fs_last_byte, and that is used:

- by lvextend as a sanity check after the fs resize is done.  So, it could
  be made optional for lvextend.

- by lvreduce to check if the fs has already been sufficiently shrunk, so
  the fs shrink command can be skipped.  Perhaps for btrfs, always require
  the fs shrink command to be run, and always make fs_last_byte large enough
  to do that.

Dave


  reply	other threads:[~2025-03-10 16:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-10  8:35 Request for comments about support btrfs in lvresize Glass Su
2025-03-10 16:24 ` David Teigland [this message]
2025-03-11  1:47   ` Glass Su
2025-03-11  2:03     ` Heming Zhao
2025-03-11 15:30     ` David Teigland

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=Z88QTwcyqqn-faz_@redhat.com \
    --to=teigland@redhat.com \
    --cc=glass.su@suse.com \
    --cc=heming.zhao@suse.com \
    --cc=lvm-devel@lists.linux.dev \
    --cc=zkabelac@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.