Re: SetFS

On 2007-02-28, Ted Zlatanov <tzz-mIZUurteI1BWk0Htik3J/[email protected]> wrote:
> On Wed, 28 Feb 2007 10:20:33 +0000 (UTC) Tuomo Valkonen <[email protected]> wrote: 
>
> TV> In fact, for tab-completion to work nicely, most tags should 
> TV> perhaps be listed. Ideally the application in question would 
> TV> do the pruning/clustering as suited to the task at hand, but 
> TV> in a FUSE plugin for applications (mostly) unaware of SetFS, 
> TV> we do not have the luxury of that. But for 'ls' output the whole
> TV> list can be unusably long. 
>
> Just like `ls', I don't think you should filter out results, just
> write a filter tool or an option to make the list usable.

It's not really filtering out anything, just producing a dynamic
hierarchy for the *nix tools that have been written for hierarchic
file systems. I think the default behaviour should be adjusted for
them, not tools aware of SetFS, which can, of course, use other 
methods.

If a simple list of tags is sufficient, then #options in the path 
could do it, but if the real search results are wanted, we don't 
want to cram them down through `readdir`. (I'm thinking of a FUSE 
plugin here constantly!) Therefore some other communication method 
is needed. One very simple option is a special read-only file with 
an additional #listing or some such element in the path. So if our
file system had the files foo/bar, foo/bar/baz, and foo/quk, then 
the read-only file foo/#listing could, for example, have the contents

	bar
	bar/baz
	quk

(You don't want to pass that slash down readdir!) Some additional
information might also be passed in this file (or a file with 
additional #options), if the FS can do it more efficiently during
the search than it would be for the application to obtain that 
information for each file separately. 

(If we pass the set identifier down the file instead of an internal 
numeric object identifier -- inode number, if you will -- the inode 
will probably need to be accessed during the search for each of the 
results, and therefore additional information is quickly available 
during the search. Contrast this with traditional unix file systems, 
like ext3, where `echo /usr/bin/*` is immediate, while `ls /usr/bin/*`
is not quite as fast. This is because the latter has to read the inode
`stat`, whereas the former doesn't. #listing could, of course, just 
list inode numbers, and another channel be provided for converting 
inode numbers to tag sets or other information. I'm not sure which 
behaviour is preferrable, although I do think exposing inode numbers
is a bit ugly.)

-- 
Tuomo