> > > basically like PageWriteback(), but for read-in. > > > > OK it could be done, possibly at great pain. But why is it important? > > Maybe not that great if mark all readahead pages as, well, readahead, > and do the same for readpage (essnetially it is the same). It isn't that easy. Readahead (->readpages()) is best effort, and is allowed to not bring the page uptodate, since it will be retried with ->readpage(). I don't know whether any filesystems actually do that, but it's allowed nonetheless. > > What's the use case where it matters that splice-in should not block > > on the read? > > To be able to transfer what was already read? That needs the consumer to be non-blocking... Umm, one more reason why the ->confirm() stuff is currently busted: pipe_read() will block on such a buffer even if pipe file is marked O_NONBLOCK. Fixing that would take a hell of a lot of added complexity in pipe_poll(), etc... Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
