From: David Sterba <dsterba@suse.cz>
To: Anand Jain <anand.jain@oracle.com>
Cc: linux-btrfs@vger.kernel.org, dsterba@suse.com, l@damenly.su
Subject: Re: [PATCH RFC V5 2/4] btrfs: use latest_dev in btrfs_show_devname
Date: Thu, 2 Sep 2021 15:47:29 +0200 [thread overview]
Message-ID: <20210902134729.GT3379@twin.jikos.cz> (raw)
In-Reply-To: <5d254bebd4afefa42e8c56ae1002354c04c7112c.1629780501.git.anand.jain@oracle.com>
On Tue, Aug 24, 2021 at 01:05:20PM +0800, Anand Jain wrote:
> RFC because,
> With this patch, /proc/self/mounts might not show the lowest devid
> device as we did before. Instead we show the device that has the greatest
> generation and, we used it to build the tree. IMO it is ok because
> /proc/self/mounts should show a device the belongs to the fsid not,
> necessarily the lowest devid device as devid is internal to btrfs.
> IMO this won't affect the ABI?
I tend to agree, the only thing that should be consistent that any
number of mounts of the same filesystem (eg. by subvolume) should print
the same device path. But given that fs_devices is shared then the same
output is guaranteed. The time when the latest_bdev changes is after
remove or replace, that's an intermediate state so the results may vary.
And maybe when printing the device by which the fs was mounted is more
correct, as it may be different from the lowest id and that could
potentially be confusing. The commit 9c5085c14798 ("Btrfs: implement
->show_devname") adding the show_devname callback even mentions not
showing the mount device as a drawback. The multi-device fs devices
should be treated equally for the purpose of mount.
next prev parent reply other threads:[~2021-09-02 13:47 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-24 5:05 [PATCH V5 0/4] btrf_show_devname related fixes Anand Jain
2021-08-24 5:05 ` [PATCH V5 1/4] btrfs: convert latest_bdev type to struct btrfs_device and rename Anand Jain
2021-08-24 5:05 ` [PATCH RFC V5 2/4] btrfs: use latest_dev in btrfs_show_devname Anand Jain
2021-09-02 13:47 ` David Sterba [this message]
2021-08-24 5:05 ` [PATCH V5 3/4] btrfs: update latest_dev when we sprout Anand Jain
2021-08-24 5:05 ` [PATCH V5 4/4] btrfs: fix comment about the btrfs_show_devname Anand Jain
2021-09-02 14:26 ` David Sterba
2021-09-02 14:38 ` David Sterba
2021-08-30 22:41 ` [PATCH V5 0/4] btrf_show_devname related fixes Anand Jain
2021-08-31 14:28 ` Su Yue
2021-08-31 15:41 ` David Sterba
2021-08-31 23:55 ` Su Yue
2021-08-31 23:58 ` Su Yue
2021-09-02 15:26 ` David Sterba
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=20210902134729.GT3379@twin.jikos.cz \
--to=dsterba@suse.cz \
--cc=anand.jain@oracle.com \
--cc=dsterba@suse.com \
--cc=l@damenly.su \
--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 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.