Re: [LSF/MM/BPF TOPIC] Measuring limits and enhancing buffered IO

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Feb 28, 2024 at 09:13:05AM +1100, Dave Chinner wrote:
> On Tue, Feb 27, 2024 at 05:07:30AM -0500, Kent Overstreet wrote:
> > AFAIK every filesystem allows concurrent direct writes, not just xfs,
> > it's _buffered_ writes that we care about here.
> 
> We could do concurrent buffered writes in XFS - we would just use
> the same locking strategy as direct IO and fall back on folio locks
> for copy-in exclusion like ext4 does.

ext4 code doesn't do that. it takes the inode lock in exclusive mode,
just like everyone else.

> The real question is how much of userspace will that break, because
> of implicit assumptions that the kernel has always serialised
> buffered writes?

What would break?

> > If we do a short write because of a page fault (despite previously
> > faulting in the userspace buffer), there is no way to completely prevent
> > torn writes an atomicity breakage; we could at least try a trylock on
> > the inode lock, I didn't do that here.
> 
> As soon as we go for concurrent writes, we give up on any concept of
> atomicity of buffered writes (esp. w.r.t reads), so this really
> doesn't matter at all.

We've already given up buffered write vs. read atomicity, have for a
long time - buffered read path takes no locks.




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux