On 10/30/23 02:15, Amir Goldstein wrote: > On Mon, Oct 30, 2023 at 6:16 AM John Ericson > <john.ericson@obsidian.systems> wrote: > >> We aren't working on this at the moment, but I did have some off-list discuss discussion with Amir Goldstein. I wanted to include our correspondence on this list for posterity --- e.g. us working on this later, someone else working on this later, etc., and he said that is fine, so here it is. It took me a while to find the time splice together all the replies and their quotes, but now I have it. >> >> > Thanks for the follow up. Sure thing. It was lingering on my TODO list for too long. Getting it done feels much better. >> One thing I'll add is that while I still think this "resetting" operation is a good feature for overlay fs in general (and not just our use-case), the FUSE passthrough work (from Android most recently, not yet merged AFIAK) would be an even better fit for our use-case than overlay fs. I don't know if upstreaming that is still being pursued, but if it is, it seams reasonable to just wait for it. >> > v14 just posted 2 weeks ago: > https://lore.kernel.org/linux-fsdevel/20231016160902.2316986-1-amir73il@xxxxxxxxx/ > > - All issues that Miklos mentioned as must for first release have been addressed > - Only xfstests regressions are due to no invalidate of attribute > cache on mmap writes > > I don't know of anything that should be blocking this work from being > merged to v6.8, but it does not mean that it will be merged ;) Oh great! I very much failed to google that, only seeing the 2021 thread. >> Indeed, FUSE passthrough ought to be a good replacement for the whole gamut of exotic bind/union/overlay mounting without out adding endless more functionality and code to the kernel. >> > If you are expecting that FUSE passthough will make overlayfs redundant > you have very high expectations from FUSE passthrough. > > First of all, the work that was proposed for upstream is only for FUSE file io > passthrough, which means that any non io operation still has a significant > performance overhead with FUSE compared to overlayfs. > > The plan of FUSE BPF, that was presented by Android team has the > potential to bring FUSE passthrough performance much closer to overlayfs > but that is still a long way to go. Yeah that makes sense. I am not sure exactly what the boundary is between IO and non-IO modifications, but I suspect we could luck out there. (We'd be putting together a single "virtual" directory whose children are all - "real" - taken entirely from just one or the other underlying "layers" and not merged from both - read-only, as an added bonus ) I meant less that I expect phenomenal performance in 6.8 for arbitrary former overlayfs usage :), than that it's nice to be "on the right track" with the right sort of architecture for both performance and expressiveness eventually :). Good luck! Thanks, John
