Re: Initial patches for Incremental FS

[Amir Goldstein <amir73il@gmail.com>]

On Wed, May 8, 2019 at 11:10 PM Eugene Zemtsov <ezemtsov@google.com> wrote:
>
> > This really sounds to me like the properties of a network filesystem
> > with local cache. It seems that you did a thorough research, but
> > I am not sure that you examined the fscache option properly.
> > Remember, if an existing module does not meet your needs,
> > it does not mean that creating a new module is the right answer.
> > It may be that extending an existing module is something that
> > everyone, including yourself will benefit from.
>
> > I am sure you can come up with caching policy that will meet your needs
> > and AFAIK FUSE protocol supports invalidating cache entries from server
> > (i.e. on "external" changes).
>
> You’re right. On a very high level it looks quite plausible that incfs can be
> replaced by a combination of
> 1. fscache interface change to accomodate compression, hashes etc
> 2. a new fscache backend
> 3. a FUSE change, that would allow FUSE to load data to fscache and server data
>     from directly fscache.
>
> After it is all done, FUSE and fscache will have more features and support more
> use cases for years to come. But this approach is not without
> tradeoffs, features
> increase support burden and FUSE interface changes are almost
> impossible to deprecate.
>
> On the other hand we have a simple self-contained module, which handles
> incremental app loading for Android. All in all, incfs currently has
> about 6KLOC,
> where only 3.5KLOC is actual kernel code. It is not likely to be used “as is”
> for other purposes, but it doesn’t increase already significant complexity of
> fscache, FUSE, and VFS. People working with those components won’t need to fret
> about extra hooks and corner cases created for incremental app loading.
> If for some reason incfs doesn’t gain wide adoption, it can be relatively
> painlessly removed from the kernel.
>

If you add NEW fscache APIs you won't risk breaking the old ones.
You certainly won't make VFS more complex because you won't be
changing VFS.
You know what, even if you do submit incfs a new user space fs, without FUSE,
I'd rather that you used fscache frontend/backend design, so that at
least it will
make it easier for someone else in the community to take the backend parts
and add fronend support to FUSE or any other network fs.

And FYI, since fscache is an internal kernel API, the NEW interfaces could
be just as painlessly removed if the incfs *backend* doesn't gain any adoption.

> Having a standalone module is very important for me on a yet another level.
> It helps in porting it to older kernels. Patches scattered across fs/ substree
> will be less portable and self contained. (BTW this is the reason to have
> a version file in sysfs - new versions of incfs can be backported to
> older kernels.)
>
> Hopefully this will clarify why I think that VFS interface is the right boundary
> for incremental-fs. It is sufficiently low-level to achieve all
> goals of incremental app loading, but at the same time sufficiently isolated
> not to meddle with the rest of the kernel.
>
> Thoughts?
>

I think you have made the right choice for you and for the product you are
working on to use an isolated module to provide this functionality.

But I assume the purpose of your posting was to request upstream inclusion,
community code review, etc. This is not likely to happen when the
implementation and design choices are derived from Employer needs vs.
the community needs. Sure, you can get high level design review, which is
what *this* is, but I recon not much more.

This discussion has several references to community projects that can benefit
from this functionality, but not in its current form.

This development model has worked well in the past for Android and the Android
user base leverage could help to get you a ticket to staging, but eventually,
those modules (e.g. ashmem) often do get replaced with more community oriented
APIs.

Thanks,
Amir.