On Fri, Jan 17, 2020 at 12:05:36PM +0100, Jan Kara wrote: > On Fri 17-01-20 17:39:03, yukuai (C) wrote: > > On 2020/1/16 23:32, Jan Kara wrote: > > > Thanks for the report and the patch. But the data integrity when mixing > > > buffered and direct IO like this is best effort only. We definitely do not > > > want to sacrifice performance of common cases or code complexity to make > > > cases like this work reliably. > > > > In the patch, the only thing that is diffrent is that iomap_begin() will > > be called for each page. However, it seems the performance in sequential > > read didn't get worse. Is there a specific case that the performance > > will get worse? > > Well, one of the big points of iomap infrastructure is that you call > filesystem once to give you large extent instead of calling it to provide > allocation for each page separately. The additional CPU overhead will be > visible if you push the machine hard enough. So IMHO the overhead just is > not worth it for a corner-case like you presented. But that's just my > opinion, Darrick and Christoph are definitive arbiters here... Does the problem go away if you apply[1]? If I understand the race correctly, marking the extents unwritten and leaving them that way until after we've written the disk should eliminate the exposure vector...? :) [1] https://lore.kernel.org/linux-xfs/157915535059.2406747.264640456606868955.stgit@magnolia/ --D > Honza > > -- > Jan Kara <jack@xxxxxxxx> > SUSE Labs, CR
