linux-kernel - Re: [RFC] xfs: fake fallocate success for always CoW inodes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251110095228.GA24387@lst.de>
Date: Mon, 10 Nov 2025 10:52:28 +0100
From: Christoph Hellwig <hch@....de>
To: Florian Weimer <fweimer@...hat.com>
Cc: Christoph Hellwig <hch@....de>, Matthew Wilcox <willy@...radead.org>,
	Hans Holmberg <hans.holmberg@....com>, linux-xfs@...r.kernel.org,
	Carlos Maiolino <cem@...nel.org>,
	Dave Chinner <david@...morbit.com>,
	"Darrick J . Wong" <djwong@...nel.org>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	libc-alpha@...rceware.org
Subject: Re: [RFC] xfs: fake fallocate success for always CoW inodes

On Mon, Nov 10, 2025 at 10:49:04AM +0100, Florian Weimer wrote:
> >> Maybe add two flags, one for the ftruncate replacement, and one that
> >> instructs the file system that the range will be used with mmap soon?
> >> I expect this could be useful information to the file system.  We
> >> wouldn't use it in posix_fallocate, but applications calling fallocate
> >> directly might.
> >
> > What do you think "to be used with mmap" flag could be useful for
> > in the file system?  For file systems mmap I/O isn't very different
> > from other use cases.
> 
> I'm not a file system developer. 8-)
> 
> The original concern was about a large file download tool that didn't
> download in sequence.  It wrote to a memory mapping directly, in
> somewhat random order.  And was observed to cause truly bad
> fragmentation in practice.  Maybe this something for posix_fadvise.

In general smart allocators (both the classic XFS allocator, and the
zoned one we're talking about here) take the file offset into account
when allocating blocks.  Additionally the VM writeback code usually
avoids writing back out of order unless writeback is forced by an
f(data)sync or memory pressuere.  So it should not be needed here,
although I won't hold my hand into the fire that fallocate won't help
with simpler allocators or really degenerate I/O patterns, but
there is nothing mmap-specific about that.

> 
> Thanks,
> Florian
---end quoted text---