From: Christoph Hellwig <hch@infradead.org>
To: Goldwyn Rodrigues <rgoldwyn@suse.de>
Cc: linux-btrfs@vger.kernel.org,
Goldwyn Rodrigues <rgoldwyn@suse.com>,
Johannes Thumshirn <johannes.thumshirn@wdc.com>,
Josef Bacik <josef@toxicpanda.com>
Subject: Re: [PATCH 06/21] btrfs: wait ordered range before locking during truncate
Date: Tue, 7 Mar 2023 09:03:49 -0800 [thread overview]
Message-ID: <ZAdudW1SCWmnboOb@infradead.org> (raw)
In-Reply-To: <e9629218282f3e016517f1280b48c5d194fd7c40.1677793433.git.rgoldwyn@suse.com>
So, one thing I've been wondering about for a while is why btrfs even
does all these explicit waits for ordered extents. The ordered_extent
is effectively a mechanism to describe a range of I/O.
So why can't we use the nornal mechanisms to wait for I/O, that is the
completion of writeback for buffered I/O (i.e. filemap_fdatawait*)
and inode_dio_wait for direct I/O? I've been wanting to look deeper
into this for a while, so this might be a good time to bring it up.
next prev parent reply other threads:[~2023-03-07 17:10 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1677793433.git.rgoldwyn@suse.com>
2023-03-02 22:24 ` [PATCH 01/21] fs: readahead_begin() to call before locking folio Goldwyn Rodrigues
2023-03-06 16:53 ` Christoph Hellwig
2023-03-02 22:24 ` [PATCH 02/21] btrfs: add WARN_ON() on incorrect lock range Goldwyn Rodrigues
2023-03-08 19:28 ` Boris Burkov
2023-03-02 22:24 ` [PATCH 03/21] btrfs: Add start < end check in btrfs_debug_check_extent_io_range() Goldwyn Rodrigues
2023-03-08 19:29 ` Boris Burkov
2023-03-02 22:24 ` [PATCH 04/21] btrfs: make btrfs_qgroup_flush() non-static Goldwyn Rodrigues
2023-03-02 22:24 ` [PATCH 05/21] btrfs: Lock extents before pages for buffered write() Goldwyn Rodrigues
2023-03-02 22:24 ` [PATCH 06/21] btrfs: wait ordered range before locking during truncate Goldwyn Rodrigues
2023-03-07 17:03 ` Christoph Hellwig [this message]
2023-03-02 22:24 ` [PATCH 07/21] btrfs: lock extents while truncating Goldwyn Rodrigues
2023-03-02 22:24 ` [PATCH 08/21] btrfs: no need to lock extent while performing invalidate_folio() Goldwyn Rodrigues
2023-03-02 22:24 ` [PATCH 09/21] btrfs: lock extents before folio for read()s Goldwyn Rodrigues
2023-03-02 22:24 ` [PATCH 10/21] btrfs: lock extents before pages in writepages Goldwyn Rodrigues
2023-03-02 22:24 ` [PATCH 11/21] btrfs: locking extents for async writeback Goldwyn Rodrigues
2023-03-08 19:13 ` Boris Burkov
2023-03-02 22:24 ` [PATCH 12/21] btrfs: lock extents before pages - defrag Goldwyn Rodrigues
2023-03-02 22:24 ` [PATCH 13/21] btrfs: Perform memory faults under locked extent Goldwyn Rodrigues
2023-03-02 22:24 ` [PATCH 14/21] btrfs: writepage fixup lock rearrangement Goldwyn Rodrigues
2023-03-02 22:25 ` [PATCH 15/21] btrfs: lock extent before pages for encoded read ioctls Goldwyn Rodrigues
2023-03-02 22:25 ` [PATCH 16/21] btrfs: lock extent before pages in encoded write Goldwyn Rodrigues
2023-03-02 22:25 ` [PATCH 17/21] btrfs: btree_writepages lock extents before pages Goldwyn Rodrigues
2023-03-02 22:25 ` [PATCH 18/21] btrfs: check if writeback pages exist before starting writeback Goldwyn Rodrigues
2023-03-02 22:25 ` [PATCH 19/21] btrfs: lock extents before pages in relocation Goldwyn Rodrigues
2023-03-02 22:25 ` [PATCH 20/21] btrfs: Add inode->i_count instead of calling ihold() Goldwyn Rodrigues
2023-03-07 17:06 ` Christoph Hellwig
2023-03-08 23:03 ` Goldwyn Rodrigues
2023-03-09 9:14 ` Christoph Hellwig
2023-03-11 3:52 ` Goldwyn Rodrigues
2023-03-02 22:25 ` [PATCH 21/21] btrfs: debug extent locking Goldwyn Rodrigues
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=ZAdudW1SCWmnboOb@infradead.org \
--to=hch@infradead.org \
--cc=johannes.thumshirn@wdc.com \
--cc=josef@toxicpanda.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=rgoldwyn@suse.com \
--cc=rgoldwyn@suse.de \
/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.