On Thu, Sep 24, 2020 at 04:22:11PM +0100, Matthew Wilcox wrote: > On Thu, Sep 24, 2020 at 11:12:59AM -0400, Brian Foster wrote: > > On Thu, Sep 24, 2020 at 02:59:00PM +0100, Matthew Wilcox wrote: > > > On Thu, Sep 24, 2020 at 09:12:35AM -0400, Brian Foster wrote: > > > > On Thu, Sep 24, 2020 at 01:56:08PM +0100, Matthew Wilcox (Oracle) wrote: > > > > > For filesystems with block size < page size, we need to set all the > > > > > per-block uptodate bits if the page was already uptodate at the time > > > > > we create the per-block metadata. This can happen if the page is > > > > > invalidated (eg by a write to drop_caches) but ultimately not removed > > > > > from the page cache. > > > > > > > > > > This is a data corruption issue as page writeback skips blocks which > > > > > are marked !uptodate. > > > > > > > > Thanks. Based on my testing of clearing PageUptodate here I suspect this > > > > will similarly prevent the problem, but I'll give this a test > > > > nonetheless. > > > > > > > > I am a little curious why we'd prefer to fill the iop here rather than > > > > just clear the page state if the iop data has been released. If the page > > > > is partially uptodate, then we end up having to re-read the page > > > > anyways, right? OTOH, I guess this behavior is more consistent with page > > > > size == block size filesystems where iop wouldn't exist and we just go > > > > by page state, so perhaps that makes more sense. > > > > > > Well, it's _true_ ... the PageUptodate bit means that every byte in this > > > page is at least as new as every byte on storage. There's no need to > > > re-read it, which is what we'll do if we ClearPageUptodate. > > > > Yes, of course. I'm just noting the inconsistent behavior between a full > > and partially uptodate page. > > Heh, well, we have no way of knowing. We literally just threw away > the information about which blocks are uptodate. So the best we can > do is work with the single bit we have. We do know that there are no > dirty blocks left on the page at this point (... maybe we should add a > VM_BUG_ON(!PageUptodate && PageDirty)). > Right.. > Something we could do is summarise the block uptodate information in > the 32/64 bits of page_private without setting PagePrivate. That would > cause us to still allocate an iop so we can track reads/writes, but we > might be able to avoid a few reads. > > But I don't think it's worth it. Partially uptodate pages are not what > we should be optimising for; we should try to get & keep pages uptodate. > After all, it's a page cache ;-) > Fair enough. I was thinking about whether we could ensure the page is released if releasepage() effectively invalidated the page content (or avoid the release if we know the mapping won't be removed), but that appears to be nontrivial given the refcount interdependencies between page private and removing the mapping. I.e., the private data can hold a reference on the page and remove_mapping() wants to assume that the caller and page cache hold the last references on the page. Brian
