On Thu, Mar 14, 2019 at 02:37:55PM -0600, Ross Zwisler wrote: > > So perhaps the caller should be waiting on a specific range to bound > > the wait (e.g. isize as the end of the wait) rather than using the > > default "keep going until the end of file is reached" semantics? > > The call to __filemap_fdatawait_range() is happening via the jdb2 code: > > jbd2_journal_commit_transaction() > journal_finish_inode_data_buffers() > filemap_fdatawait_keep_errors() > __filemap_fdatawait_range(end = LLONG_MAX) I think jbd2 needs to call a new filemap_fdatawait_range_keep_errors() (to be defined in mm/filemap.c). > Would it have to be an extending write? Or could it work the same if > you have one thread just moving forward through a very large file, > dirtying pages, and the __filemap_fdatawait_range() call will just > keep finding new pages as it moves forward through the big file? No, that case is fine because we'll eventually make our way to the end of the file and stop. In the long term I want to get rid of data=ordered mode (while still avoids the stale data problem) without going through all of this hair so we don't have to call filemap_fdatawait from the commit thread. The real problem is that ext2/3 allocates blocks, updates the inode metadata, and then writes the data blocks out. What we need to do is to swap the 2nd and 3rd steps.... - Ted
