Re: [fuse-devel] Getting access to libfuses filename/inode cache

[Goswin v. B. <gos...@we...>]

Miklos Szeredi <mi...@sz...> writes:

> Goswin von Brederlow <gos...@we...> writes:
>
>> Hi,
>>
>> I'm wondering if it would be feasable to get access to the file names
>> cached for the highlevel interface, esspecially when -o noforget is
>> used.
>>
>> Why? Well, here it goes...
>>
>> I'm bootstraping a debian installation, set up a fuse filesystem over
>> it, export it via NFS and then boot that in kvm nfs-root and run
>> it through its paces. On umount the fuse filesystem outputs a list of
>> all files used while it was mounted. That list of used files is then
>> used to create a minimal initrd image of the system that will be booted
>> via PXE on a HPC cluster. The initrd contains all the files needed for
>> operations and nothing extra to preserve ram.
>>
>> Currently I keep a list of all used files myself in my fuse FS. But with
>> -o noforget that list should already completly exist within libfuse,
>> right? So me keeping a list myself is a total waste of memory not to
>> mention code if only I can get at the list maintained inside libfuse.
>>
>>
>> Going one step further wouldn't it make sense if libfuse could dump its
>> cache on shutdown and reimport that when started again to preserve the
>> inode numbers of files between restarts? That would allow restarting a
>> fuse FS that is exported via NFS without the inode numbers all getting
>> changed.
>>
>> Thoughts?
>
> Yes, that would make sense.
>
> Ideally that name<->nodeid mapping would be continually be updated on
> disk (and cached for speed) which would have the advantage of not
> wasting possibly unbounded amount of memory, and also being able to
> continue after a crash.

I think that making this crash save would be a serious performance
limit. Every first getattr() of a file would need a fsync(). I would
probably use sqlite for that or something similar that abstracts all
this away.

A simpler solution would be to do this lazily. Mmap a file and allocate
all the data structures for the mapping in there. That would likely be
unrecoverable on power loss. But a fuse crash itself shouldn't corrupt
the data. Some degree of fragmentation would occur in the file though,
same as in memory.

> But a version which just dumps and restores the mapping would be a step
> in the right direction.

I think I will go for that. That is the most simple.

> Thanks,
> Miklos

Ok, great. I will see if I can get some time at work to patch this in
(and get paid for it :).

MfG
        Goswin