On 2024/8/17 12:45, Matthew Wilcox wrote: > On Mon, Aug 12, 2024 at 08:11:57PM +0800, Zhang Yi wrote: >> From: Zhang Yi <yi.zhang@xxxxxxxxxx> >> >> When doing page mkwrite, iomap_folio_mkwrite_iter() dirty the entire >> folio by folio_mark_dirty() even the map length is shorter than one >> folio. However, on the filesystem with more than one blocks per folio, >> we'd better to only set counterpart block's dirty bit according to >> iomap_length(), so open code folio_mark_dirty() and pass the correct >> length. > > We shouldn't waste any time trying to optimise writing to files through > mmap(). People have written papers about what a terrible programming > model this is. eg https://db.cs.cmu.edu/mmap-cidr2022/ > > There are some programs that do it, but they are few and far between. > I don't think it's an optimization, this is a fix, the issue is the same to the one that previous 2 patches want to fix: there left a hole with ifs dirty bit set but without any valid data and without any block allocated/reserved. This mmap() path is just once case that could lead to this issue (The case if as I said in my reply to Christoph, suppose we have a 3K regular file on a filesystem with 1K block size. If the folio size is 4K, In iomap_page_mkwrite(), it will mark all 4 bits of ifs dirty, the last one will become redundant if we expand the file to 4K later). Hence in my opinion, we need to fix this, or it's gonna be a potential problem one day. Thanks, Yi.
