From: Johannes Thumshirn <Johannes.Thumshirn@wdc.com>
To: Christoph Hellwig <hch@lst.de>, Chris Mason <clm@fb.com>,
Josef Bacik <josef@toxicpanda.com>,
David Sterba <dsterba@suse.com>
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
Christian Brauner <brauner@kernel.org>,
Eric Biggers <ebiggers@kernel.org>
Subject: Re: [PATCH 5/5] btrfs: use the super_block as holder when mounting file systems
Date: Mon, 18 Dec 2023 12:14:35 +0000 [thread overview]
Message-ID: <04e599b9-5d6d-4ac0-bf74-da9bedfb585f@wdc.com> (raw)
In-Reply-To: <20231218044933.706042-6-hch@lst.de>
On 18.12.23 05:50, Christoph Hellwig wrote:
> The file system type is not a very useful holder as it doesn't allow us
> to go back to the actual file system instance. Pass the super_block
> instead which is useful when passed back to the file system driver.
>
> This matches what is done for all other block device based file systems.
>
Small Nit:
ext4, f2fs and xfs use the super_block, erofs uses 'sb->s_type' as well
here. Reiser uses the journal and so does jfs. So while these two might
not be the best examples in the world, all other is an exaggeration.
I'd just kill the last sentence.
next prev parent reply other threads:[~2023-12-18 12:14 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-18 4:49 use the super_block as bdev holder Christoph Hellwig
2023-12-18 4:49 ` [PATCH 1/5] btrfs: always open the device read-only in btrfs_scan_one_device Christoph Hellwig
2023-12-18 4:49 ` [PATCH 2/5] btrfs: call btrfs_close_devices from ->kill_sb Christoph Hellwig
2023-12-18 12:22 ` Christian Brauner
2023-12-27 17:09 ` Eric Biggers
2023-12-18 4:49 ` [PATCH 3/5] btrfs: split btrfs_fs_devices.opened Christoph Hellwig
2023-12-18 11:56 ` Johannes Thumshirn
2023-12-18 15:01 ` Christoph Hellwig
2023-12-18 4:49 ` [PATCH 4/5] btrfs: open block devices after superblock creation Christoph Hellwig
2023-12-18 4:49 ` [PATCH 5/5] btrfs: use the super_block as holder when mounting file systems Christoph Hellwig
2023-12-18 12:14 ` Johannes Thumshirn [this message]
2023-12-18 15:02 ` Christoph Hellwig
2023-12-19 5:33 ` Gao Xiang
2023-12-19 12:19 ` Christoph Hellwig
2023-12-19 13:48 ` Gao Xiang
2023-12-18 12:20 ` use the super_block as bdev holder Johannes Thumshirn
-- strict thread matches above, loose matches on Subject: below --
2024-02-14 16:42 [PATCH 0/5] btrfs: " Johannes Thumshirn
2024-02-14 16:42 ` [PATCH 5/5] btrfs: use the super_block as holder when mounting file systems Johannes Thumshirn
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=04e599b9-5d6d-4ac0-bf74-da9bedfb585f@wdc.com \
--to=johannes.thumshirn@wdc.com \
--cc=brauner@kernel.org \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=ebiggers@kernel.org \
--cc=hch@lst.de \
--cc=josef@toxicpanda.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