On 12/10/19 6:14 PM, Dave Chinner wrote:
>> @@ -864,15 +896,29 @@ iomap_write_actor(struct inode *inode, loff_t pos, loff_t length, void *data,
>> */
>> bytes = min_t(unsigned long, PAGE_SIZE - offset,
>> iov_iter_single_seg_count(i));
>> + if (drop_page)
>> + put_page(page);
>> goto again;
>> }
>> +
>> + if (drop_page &&
>> + ((pos >> PAGE_SHIFT) != ((pos + copied) >> PAGE_SHIFT))) {
>> + if (!pagevec_add(&pvec, page))
>> + write_drop_cached_pages(&pvec, mapping);
>> + } else {
>> + if (drop_page)
>> + put_page(page);
>> + balance_dirty_pages_ratelimited(inode->i_mapping);
>> + }
>
> This looks like it's a problem: this is going to write the
> data, which can cause the extent mapping of the file to change
> beyond the range that was written (e.g. due to speculative delayed
> allocation) and so the iomap we have already cached to direct write
> behaviour may now be stale.
>
> IOWs, to be safe we need to terminate the write loop at this point,
> return to iomap_apply() and remap the range we are writing into so
> that we don't end up using a stale iomap. That kinda defeats the
> purpose of iomap - we are trying to do a single extent mapping per
> IO instead of per-page, and this pulls it back to an iomap per 16
> pages for large user IOs. And it has the issues with breaking
> delayed allocation optimisations, too.
>
> Hence, IMO, this is the wrong layer in iomap to be dealing with
> writeback and cache residency for uncached IO. We should be caching
> residency/invalidation at a per-IO level, not a per-page level.
>
> Sure, have the write actor return a flag (e.g. in the iomap) to say
> that it encountered cached pages so that we can decide whether or
> not to invalidate the entire range we just wrote in iomap_apply, but
> doing it between mappings in iomap_apply means that the writeback is
> done once per user IO, and cache invalidation only occurs if no
> cached pages were encountered during that IO. i.e. add this to
> iomap_apply() after ops->iomap_end() has been called:
>
>
> if (flags & RWF_UNCACHED) {
> ret = filemap_write_and_wait_range(mapping, start, end);
> if (ret)
> goto out;
>
> if (!drop_cache)
> goto out;
>
> /*
> * Try to invalidate cache pages for the range we
> * just wrote. We don't care if invalidation fails
> * as the write has still worked and leaving clean
> * uptodate pages * in the page cache isn't a
> * corruption vector for uncached IO.
> */
> invalidate_inode_pages2_range(mapping,
> start >> PAGE_SHIFT, end >> PAGE_SHIFT);
> }
> out:
> return written ? written : ret;
> }
I really like this, and some variant of that solution can also be
applied to the non-iomap case. It'll make for a cleaner implementation
as well.
Once we do it per-write we'll have solved the performance and iomap
weirdness, but it does mean that we need to make a decision on when to
invalidate. For the per-page case it's clear - if the page is already
there, leave it. If not, (attempt to) kill it. For the full write range,
what if just one page was not there? Do we invalidate then? What if one
page was there?
I'm going to move forward with the notion that if we had to allocate any
page in the range, we invalidate the range. Only ranges that were fully
cached already will remain in the cache. I think those semantics make
the most sense.
> Note that this doesn't solve the write error return issue. i.e.
> if filemap_write_and_wait_range() fails, should that error be
> returned or ignored?
I think we should handle this exactly like we do the O_DIRECT case on
buffered IO write-and-wait.
> And that leads to my next question: what data integrity guarantees
> does RWF_UNCACHED give? What if the underlying device has a volatile
> write cache or we dirtied metadata during block allocation? i.e. to
> a user, "UNCACHED" kinda implies that the write has ended up on
> stable storage because they are saying "do not cache this data". To
> me, none of this implementation guarantees data integrity, and users
> would still need O_DSYNC or fsync() with RWF_UNCACHED IO. That seems
> sane to me (same as direct io requirements) but whatever is decided
> here, it will need to be spelled out clearly in the man page so that
> users don't get it wrong.
Fully agree, this isn't about data integrity guarantees. You will still
need the appropriate sync magic to make it safe. This is exactly like
O_DIRECT, and I think we should retain those exact same semantics for
the RWF_UNCACHED case.
Thanks for taking a look at this! I'll respin (and re-test) with the
write side changed.
--
Jens Axboe
