On Sat, Jan 27, 2024 at 09:32:42AM +1100, Dave Chinner wrote: > > but the problem is that Microsoft half-arsed their support for holes. > > See my other mail in this thread. > > Why does that matter? It's exactly the same problem with any other > filesytsem that doesn't support sparse files. > > All I said is that IO operations beyond the "valid size" should > be treated like a operating in a hole - I pass no judgement on the > filesystem design, implementation or level of sparse file support > it has. ALl it needs to do is treat the "not valid" size range as if > it was a hole or unwritten, regardless of whether the file is sparse > or not.... > > > truncate the file up to 4TB > > write a byte at offset 3TB > > > > ... now we have to stream 3TB of zeroes through the page cache so that > > we can write the byte at 3TB. > > This behaviour cannot be avoided on filesystems without sparse file > support - the hit of writing zeroes has to be taken somewhere. We > can handle this in truncate(), the write() path or in ->page_mkwrite > *if* the zeroing condition is hit. There's no need to do it at > mmap() time if that range of the file is not actually written to by > the application... It's really hard to return -ENOSPC from ->page_mkwrite. At best you'll get a SIGBUS or SEGV. So truncate() or mmap() are the only two places to do it. And if we do it in truncate() then we can't take any advantage of the limited "hole" support the filesystem has. Most files are never mmaped, much less mapped writable. I think doing it in mmap() is the best of several bad options.
