YAMAMOTO Takashi wrote:
>> YAMAMOTO Takashi wrote:
>>
>>> because you can use the same mechanism for mounted filesystem and
>>> unmounted filesystems.
>> I think I understand what you mean here, but can you elaborate on how
>> you see this implemented?
> 
> as i said, via a generic upcall mechanism.
> i don't have concrete ideas of implemetation details yet.
> i think i will implement upcalls for nfsd, so you can use it if you are
> patient enough. :)

What bothers me isn't the mechanism, but the implications of moving a
database that is in kernelspace (for a reason) to userspace. How do you
suggest to protect this process from things like root killing it?

>> (IIUC, you're talking about a userland daemon that the kernel will
>> dispatch queries to, and cache the result of the answers, so that it
>> doesn't matter when a file-system is mounted, because the query will
>> be made as soon as missing information is needed -- like meta-data
>> paging?)
> 
> yes.
> 
> an interesting question is what to use as query keys.
> eg. pathname, file handles, etc.
> 
> considering how fileassoc works, file handles sound more natural,
> but it can yield some difficulties for loaders.
> otoh, if you use pathnames, you might need to implement the file_to_path
> feature.

...which we talked about already, and I understand isn't that
straightforward to implement?

-e.