On Tue, 6 Aug 2019, Jeff Layton wrote: > On Tue, 2019-08-06 at 03:27 +0000, Sage Weil wrote: > > On Mon, 5 Aug 2019, Jeff Layton wrote: > > > xfstest generic/451 intermittently fails. The test does O_DIRECT writes > > > to a file, and then reads back the result using buffered I/O, while > > > running a separate set of tasks that are also doing buffered reads. > > > > > > The client will invalidate the cache prior to a direct write, but it's > > > easy for one of the other readers' replies to race in and reinstantiate > > > the invalidated range with stale data. > > > > Maybe a silly question, but: what if the write path did the invalidation > > after the write instead of before? Then any racing read will see the new > > data on disk. > > > > I tried that originally. It reduces the race window somewhat, but it's > still present since a reply to a concurrent read can get in just after > the invalidation occurs. You really do have to serialize them to fix > this, AFAICT. I've always assumed that viewing the ordering for concurrent operations as non-deterministic is the only sane approach. If the read initiates before the write completes you have no obligation to reflect the result of the write. Is that what you're trying to do? sage
