On Wed, Dec 18, 2024 at 11:15:42AM +0000, John Garry wrote: > On 17/12/2024 07:08, Christoph Hellwig wrote: > > On Fri, Dec 13, 2024 at 04:56:38PM -0800, Darrick J. Wong wrote: > > > > > "If you receive -EBADMAP, then call fallocate(FALLOC_FL_MAKE_OVERWRITE) > > > > > to force all the mappings to pure overwrites." > > > > > > > > Ewwwwwwwwwwwwwwwwwwwww. > > > > > > > > That's not a sane API in any way. > > > > > > Oh I know, I'd much rather stick to the view that block untorn writes > > > are a means for programs that only ever do IO in large(ish) blocks to > > > take advantage of a hardware feature that also wants those large > > > blocks. > > > > I (vaguely) agree ith that. > > > > > And only if the file mapping is in the correct state, and the > > > program is willing to *maintain* them in the correct state to get the > > > better performance. > > > > I kinda agree with that, but the maintain is a bit hard as general > > rule of thumb as file mappings can change behind the applications > > back. So building interfaces around the concept that there are > > entirely stable mappings seems like a bad idea. > > I tend to agree. As long as it's a general rule that file mappings can change even after whatever prep work an application tries to do, we're never going to have an easy time enabling any of these fancy direct-to-storage tricks like cpu loads and stores to pmem, or this block-untorn writes stuff. > > > > > I don't want xfs to grow code to write zeroes to > > > mapped blocks just so it can then write-untorn to the same blocks. > > > > Agreed. > > > > So if we want to allow large writes over mixed extents, how to handle? > > Note that some time ago we also discussed that we don't want to have a > single bio covering mixed extents as we cannot atomically convert all > unwritten extents to mapped.
