Re: "Resetting" an overlay fs entry; clearing the upper layer and revealing the lower layer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Filesystems Devel]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux