Subject: Re: Pending entries support for fileassoc(9)
To: YAMAMOTO Takashi <firstname.lastname@example.org>
From: Elad Efrat <elad@NetBSD.org>
Date: 12/28/2007 13:43:08
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
> 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
...which we talked about already, and I understand isn't that
straightforward to implement?