Re: Async direct IO write vs buffered read race

[Jeff Moyer <jmoyer@redhat.com>]

Lukas Czerner <lczerner@redhat.com> writes:

>> The thing we do is a best effort thing that more or less guarantees that if
>> you do say buffered IO and direct IO after that, it will work reasonably.
>> However if direct and buffered IO can race, bad luck for your data. I don't
>> think we want to sacrifice any performance of AIO DIO (and offloading of
>> direct IO completion to a workqueue so that we can do invalidation costs
>> noticeable mount of performance) for supporting such usecase.
>
> What Jeff proposed would sacrifice performance for the case where AIO
> DIO write does race with buffered IO - the situation we agree is not ideal
> and should be avoided anyway. For the rest of AIO DIO this should have no
> effect right ? If true, I'd say this is a good effort to make sure we do
> not have disparity between page cache and disk.

Exactly.  Jan, are you concerned about impacting performance for mixed
buffered I/O and direct writes?  If so, we could look into restricting
the process context switch further, to just overlapping buffered and
direct I/O (assuming there are no locking issues).

Alternatively, since we already know this is racy, we don't actually
have to defer I/O completion to process context.  We could just complete
the I/O as we normally would, but also queue up an
invalidate_inode_pages2_range work item.  It will be asynchronous, but
this is best effort, anyway.

As Eric mentioned, the thing that bothers me is that we have invalid
data lingering in the page cache indefinitely.

Cheers,
Jeff