READ_PLUS in NetFS? Re: [PATCH v10 30/35] netfs: Simplify read abandonment
Aurélien Couderc <[email protected]>
| Newsgroups | dev.linux.lists.netfs,dev.linux.lists.v9fs,org.kernel.vger.ceph-devel,org.kernel.vger.linux-cifs,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-nfs,org.ozlabs.lists.linux-erofs |
|---|---|
| Message-ID | <CA+1jF5qPZUhCevwbu7zQDEVWss6gMdoDMhqKqH3k7v=WStRtEA@mail.gmail.com> |
On Mon, Aug 24, 2026 at 5:04 PM David Howells <[email protected]> wrote: > > Currently, if one or more of the subrequests in a read request fails, the > read collection algorithm will attempt to salvage folios that are fully > downloaded but that span multiple subreqs, provided all of the contributory > subreqs succeeded, but this makes the algorithm quite complicated as a > subreq can contribute to multiple folios and a folio can be contributed to > by multiple subreqs. > > Simplify this by just abandoning the rest of a read request once a > permanently failed subreq is hit. This is what read_folio, DIO/unbuffered > read, gap filling, RMW and write preload all need to do; readahead is the > odd one out as it doesn't have any return other than unlocking folios. > > With this change, even for readahead, the rest of the read is simply > abandoned; read() and suchlike will call ->read_folio() on each > non-uptodate folio to retry and retrieve the error. > > Note that retryable failures still get retried by netfslib as part of the > request as before. What about READ_PLUS, i.e. sparse file reads? If you do this kind of work of handling partial abandonment, can such a work also benefit READ_PLUS? Aurélien -- Aurélien Couderc <[email protected]> Big Data/Data mining expert, chess enthusiast