On Fri, Jan 26, 2024 at 12:22:32PM +1100, Dave Chinner wrote: > On Thu, Jan 25, 2024 at 07:19:45PM +0900, Namjae Jeon wrote: > > We need to consider the case that mmap against files with different > > valid size and size created from Windows. So it needed to zero out in mmap. > > That's a different case - that's a "read from a hole" case, not a > "extending truncate" case. i.e. the range from 'valid size' to EOF > is a range where no data has been written and so contains zeros. > It is equivalent to either a hole in the file (no backing store) or > an unwritten range (backing store instantiated but marked as > containing no valid data). > > When we consider this range as "reading from a hole/unwritten > range", it should become obvious the correct way to handle this case > is the same as every other filesystem that supports holes and/or > unwritten extents: the page cache page gets zeroed in the > readahead/readpage paths when it maps to a hole/unwritten range in > the file. > > There's no special locking needed if it is done this way, and > there's no need for special hooks anywhere to zero data beyond valid > size because it is already guaranteed to be zeroed in memory if the > range is cached in the page cache..... but the problem is that Microsoft half-arsed their support for holes. See my other mail in this thread. 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.
