From: David Sterba <dsterba@suse.cz>
To: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Cc: Chris Mason <clm@fb.com>, Josef Bacik <josef@toxicpanda.com>,
David Sterba <dsterba@suse.com>, Christoph Hellwig <hch@lst.de>,
linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/5] btrfs: always open the device read-only in btrfs_scan_one_device
Date: Mon, 19 Feb 2024 21:22:47 +0100 [thread overview]
Message-ID: <20240219202247.GB355@twin.jikos.cz> (raw)
In-Reply-To: <20240214-hch-device-open-v1-1-b153428b4f72@wdc.com>
On Wed, Feb 14, 2024 at 08:42:12AM -0800, Johannes Thumshirn wrote:
> From: Christoph Hellwig <hch@lst.de>
>
> btrfs_scan_one_device opens the block device only to read the super
> block. Instead of passing a blk_mode_t argument to sometimes open
> it for writing, just hard code BLK_OPEN_READ as it will never write
> to the device or hand the block_device out to someone else.
Opening for write was not meant to be for writing but also to exclude
other attempted writes.
That it's always for read seems OK, this has changed at some point and
is explained in btrfs_scan_one_device():
1356 /*
1357 * Avoid an exclusive open here, as the systemd-udev may initiate the
1358 * device scan which may race with the user's mount or mkfs command,
1359 * resulting in failure.
1360 * Since the device scan is solely for reading purposes, there is no
1361 * need for an exclusive open. Additionally, the devices are read again
1362 * during the mount process. It is ok to get some inconsistent
1363 * values temporarily, as the device paths of the fsid are the only
1364 * required information for assembling the volume.
1365 */
1366 bdev_handle = bdev_open_by_path(path, flags, NULL, NULL);
next prev parent reply other threads:[~2024-02-19 20:23 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-14 16:42 [PATCH 0/5] btrfs: use the super_block as bdev holder Johannes Thumshirn
2024-02-14 16:42 ` [PATCH 1/5] btrfs: always open the device read-only in btrfs_scan_one_device Johannes Thumshirn
2024-02-19 20:22 ` David Sterba [this message]
2024-02-14 16:42 ` [PATCH 2/5] btrfs: call btrfs_close_devices from ->kill_sb Johannes Thumshirn
2025-06-10 5:43 ` Qu Wenruo
2024-02-14 16:42 ` [PATCH 3/5] btrfs: split btrfs_fs_devices.opened Johannes Thumshirn
2024-02-14 16:42 ` [PATCH 4/5] btrfs: open block devices after superblock creation Johannes Thumshirn
2024-02-14 18:58 ` Boris Burkov
2024-02-19 20:18 ` David Sterba
2024-02-14 16:42 ` [PATCH 5/5] btrfs: use the super_block as holder when mounting file systems Johannes Thumshirn
2024-02-14 18:57 ` [PATCH 0/5] btrfs: use the super_block as bdev holder Boris Burkov
2024-02-15 5:04 ` Christoph Hellwig
-- strict thread matches above, loose matches on Subject: below --
2023-12-18 4:49 Christoph Hellwig
2023-12-18 4:49 ` [PATCH 1/5] btrfs: always open the device read-only in btrfs_scan_one_device Christoph Hellwig
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=20240219202247.GB355@twin.jikos.cz \
--to=dsterba@suse.cz \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=hch@lst.de \
--cc=johannes.thumshirn@wdc.com \
--cc=josef@toxicpanda.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@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