linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).