> 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.
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?
Thanks,
Eugene.
