From: Christoph Hellwig <hch@lst.de>
To: Florian Weimer <fweimer@redhat.com>
Cc: Matthew Wilcox <willy@infradead.org>,
Christoph Hellwig <hch@lst.de>,
Hans Holmberg <hans.holmberg@wdc.com>,
linux-xfs@vger.kernel.org, Carlos Maiolino <cem@kernel.org>,
Dave Chinner <david@fromorbit.com>,
"Darrick J . Wong" <djwong@kernel.org>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
libc-alpha@sourceware.org
Subject: Re: [RFC] xfs: fake fallocate success for always CoW inodes
Date: Thu, 6 Nov 2025 18:05:01 +0100 [thread overview]
Message-ID: <20251106170501.GA25601@lst.de> (raw)
In-Reply-To: <lhu4ir7gm1r.fsf@oldenburg.str.redhat.com>
On Thu, Nov 06, 2025 at 05:31:28PM +0100, Florian Weimer wrote:
> It's been a few years, I think, and maybe we should drop the allocation
> logic from posix_fallocate in glibc? Assuming that it's implemented
> everywhere it makes sense?
I really think it should go away. If it turns out we find cases where
it was useful we can try to implement a zeroing fallocate in the kernel
for the file system where people want it. gfs2 for example currently
has such an implementation, and we could have somewhat generic library
version of it.
> There are more always-CoW, compressing file
> systems these days, so applications just have to come to terms with the
> fact that even after posix_fallocate, writes can still fail, and not
> just because of media errors.
Yes.
next prev parent reply other threads:[~2025-11-06 17:05 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-06 13:35 [RFC] xfs: fake fallocate success for always CoW inodes Hans Holmberg
2025-11-06 13:48 ` Florian Weimer
2025-11-06 13:52 ` Christoph Hellwig
2025-11-06 14:42 ` Matthew Wilcox
2025-11-06 14:46 ` Christoph Hellwig
2025-11-11 8:31 ` Hans Holmberg
2025-11-11 9:05 ` hch
2025-11-11 9:50 ` Florian Weimer
2025-11-11 13:40 ` hch
2025-11-06 16:31 ` Florian Weimer
2025-11-06 17:05 ` Christoph Hellwig [this message]
2025-11-08 12:30 ` Florian Weimer
2025-11-09 22:15 ` Dave Chinner
2025-11-10 5:27 ` Florian Weimer
2025-11-10 9:38 ` Christoph Hellwig
2025-11-10 10:03 ` Florian Weimer
2025-11-10 20:28 ` Dave Chinner
2025-11-11 8:56 ` Christoph Hellwig
2025-11-10 9:37 ` Christoph Hellwig
2025-11-10 9:44 ` Florian Weimer
2025-11-10 21:33 ` Dave Chinner
2025-11-11 9:04 ` Christoph Hellwig
2025-11-11 9:30 ` Florian Weimer
2025-11-10 9:31 ` Christoph Hellwig
2025-11-10 9:48 ` truncatat? was, " Christoph Hellwig
2025-11-10 10:00 ` Florian Weimer
2025-11-10 9:49 ` Florian Weimer
2025-11-10 9:52 ` Christoph Hellwig
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=20251106170501.GA25601@lst.de \
--to=hch@lst.de \
--cc=cem@kernel.org \
--cc=david@fromorbit.com \
--cc=djwong@kernel.org \
--cc=fweimer@redhat.com \
--cc=hans.holmberg@wdc.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=willy@infradead.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