From: Jinliang Zheng <alexjlzheng@gmail.com>
To: david@fromorbit.com
Cc: amir73il@gmail.com, hch@lst.de, linux-xfs@vger.kernel.org
Subject: Re: [PATCH] xfs: Remove i_rwsem lock in buffered read
Date: Fri, 20 Jun 2025 21:46:01 +0800 [thread overview]
Message-ID: <20250620134601.231640-1-alexjlzheng@tencent.com> (raw)
In-Reply-To: <20190325001044.GA23020@dastard>
On Fri, 27 Dec 2024 08:50:46 +1100, Dave Chinner <david@fromorbit.com> wrote:
> On Thu, Dec 26, 2024 at 02:16:02PM +0800, Chi Zhiling wrote:
> > From: Chi Zhiling <chizhiling@kylinos.cn>
> >
> > Using an rwsem to protect file data ensures that we can always obtain a
> > completed modification. But due to the lock, we need to wait for the
> > write process to release the rwsem before we can read it, even if we are
> > reading a different region of the file. This could take a lot of time
> > when many processes need to write and read this file.
> >
> > On the other hand, The ext4 filesystem and others do not hold the lock
> > during buffered reading, which make the ext4 have better performance in
> > that case. Therefore, I think it will be fine if we remove the lock in
> > xfs, as most applications can handle this situation.
>
> Nope.
>
> This means that XFS loses high level serialisation of incoming IO
> against operations like truncate, fallocate, pnfs operations, etc.
>
> We've been through this multiple times before; the solution lies in
> doing the work to make buffered writes use shared locking, not
> removing shared locking from buffered reads.
Hi, Dave
I have a question that I haven't figured out: If shared locking are used
in buffer writes, how can the read/write atomicity mentioned by [0] provided
by xfs be guaranteed?
" "I/O is intended to be atomic to ordinary files and pipes and FIFOs.
" Atomic means that all the bytes from a single operation that started
" out together end up together, without interleaving from other I/O
" operations."
"
" i.e. that independent read()s should see a write() as a single
" atomic change. hence if you do a read() concurrently with a write(),
" the read should either run to completion before the write, or the
" write run to completion before the read().
"
" XFS is the only linux filesystem that provides this behaviour.
[0] https://lore.kernel.org/linux-xfs/20190325001044.GA23020@dastard/
thanks,
Jinliang Zheng :)
>
> A couple of old discussions from the list:
>
> https://lore.kernel.org/linux-xfs/CAOQ4uxi0pGczXBX7GRAFs88Uw0n1ERJZno3JSeZR71S1dXg+2w@mail.gmail.com/
> https://lore.kernel.org/linux-xfs/20190404165737.30889-1-amir73il@gmail.com/
>
> There are likely others - you can search for them yourself to get
> more background information.
>
> Fundamentally, though, removing locking from the read side is not
> the answer to this buffered write IO exclusion problem....
>
> -Dave.
> --
> Dave Chinner
> david@fromorbit.com
next prev parent reply other threads:[~2025-06-20 13:46 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-24 18:18 [QUESTION] Long read latencies on mixed rw buffered IO Amir Goldstein
2019-03-25 0:10 ` Dave Chinner
2019-03-25 6:51 ` Christoph Hellwig
2019-03-25 6:55 ` Amir Goldstein
2019-03-25 7:49 ` Amir Goldstein
2019-03-25 15:47 ` Darrick J. Wong
2019-03-25 16:41 ` Matthew Wilcox
2019-03-25 17:30 ` Amir Goldstein
2019-03-25 18:22 ` Matthew Wilcox
2019-03-25 19:18 ` Amir Goldstein
2019-03-25 19:40 ` Matthew Wilcox
2019-03-25 19:57 ` Amir Goldstein
2019-03-25 23:48 ` Dave Chinner
2019-03-26 3:44 ` Amir Goldstein
2019-03-27 1:29 ` Dave Chinner
2019-03-25 17:56 ` Amir Goldstein
2019-03-25 18:02 ` Christoph Hellwig
2019-03-25 18:44 ` Amir Goldstein
2019-03-25 23:43 ` Dave Chinner
2019-03-26 4:36 ` Amir Goldstein
2025-06-20 13:46 ` Jinliang Zheng [this message]
-- strict thread matches above, loose matches on Subject: below --
2024-12-26 6:16 [PATCH] xfs: Remove i_rwsem lock in buffered read Chi Zhiling
2024-12-26 21:50 ` Dave Chinner
2024-12-28 7:37 ` Chi Zhiling
2024-12-28 22:17 ` Dave Chinner
2024-12-30 2:42 ` Chi Zhiling
2025-01-07 12:13 ` Amir Goldstein
2025-01-07 17:12 ` Christoph Hellwig
2025-01-08 7:43 ` Chi Zhiling
2025-01-08 11:33 ` Amir Goldstein
2025-01-08 11:45 ` Amir Goldstein
2025-01-08 12:15 ` John Garry
2025-01-09 10:07 ` Amir Goldstein
2025-01-09 12:40 ` John Garry
2025-01-09 8:37 ` Chi Zhiling
2025-01-09 10:25 ` Amir Goldstein
2025-01-09 12:10 ` Chi Zhiling
2025-01-09 12:25 ` John Garry
2025-01-08 17:35 ` Darrick J. Wong
2025-01-09 23:28 ` Dave Chinner
2025-01-10 1:31 ` Chi Zhiling
2025-01-10 17:07 ` Amir Goldstein
2025-01-12 10:05 ` Chi Zhiling
2025-01-13 2:44 ` Darrick J. Wong
2025-01-13 5:59 ` Chi Zhiling
2025-01-13 13:40 ` Brian Foster
2025-01-13 16:19 ` Darrick J. Wong
2025-01-15 5:55 ` Christoph Hellwig
2025-01-15 21:41 ` Dave Chinner
2025-01-16 4:36 ` Christoph Hellwig
2025-01-17 22:20 ` Dave Chinner
2025-01-16 14:23 ` Brian Foster
2025-01-17 13:27 ` Amir Goldstein
2025-01-17 22:19 ` Dave Chinner
2025-01-18 13:03 ` Amir Goldstein
2025-01-20 5:11 ` Dave Chinner
2025-01-22 6:08 ` Christoph Hellwig
2025-01-22 23:35 ` Dave Chinner
2025-01-17 16:12 ` Chi Zhiling
2025-01-24 7:57 ` Chi Zhiling
2025-01-27 20:49 ` Dave Chinner
2025-01-28 5:15 ` Christoph Hellwig
2025-01-28 21:23 ` David Laight
2025-01-29 0:59 ` Dave Chinner
2025-01-29 5:20 ` Christoph Hellwig
2025-02-10 1:44 ` Chi Zhiling
2025-01-14 0:09 ` Dave Chinner
2025-01-25 8:43 ` Jinliang Zheng
2025-01-25 14:14 ` Amir Goldstein
2025-06-20 14:03 ` Jinliang Zheng
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=20250620134601.231640-1-alexjlzheng@tencent.com \
--to=alexjlzheng@gmail.com \
--cc=amir73il@gmail.com \
--cc=david@fromorbit.com \
--cc=hch@lst.de \
--cc=linux-xfs@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;
as well as URLs for NNTP newsgroup(s).