On Wed, 2005-08-24 at 18:55 +0200, Dirk Meyer wrote: > I know. I was thinking about making root always the same type, but > that sucks. An audio disc is different from the root of my fs. BTW, > how to find a disc? Is a disc always a 'removable media' or are DVDs > and AudioCD different?
It depends on what kind of attributes you want to associate. Yes, I see them as different, because DVDs have different attributes from audio CDs, and so you'd register a "dvd" type and an "audiocd" type. The vfs would provide an interface to associate a "removable" flag with new types and deal with removable types which are roots for other objects as necessary. > Yes, that's a bad hack. I guess the best solution is to have a > mountpoint. Actually I think it's a clever hack that, while conceptually kludgey, in practice won't cause any problems and should perform well. > table mountpoint > int id unique > type string > rootid int > > So for an audio disc with the entry 'removable', type is removable and > rootid the id. So we point to this table for mointpoint to have one > unique table for all mountpoints. I actually like my idea better. This solution means a new table that we have to keep updated. If the problem really is the 100 million file limit in my solution, then we could concatenate root_type and root_id as strings. While theoretically better, I like that idea less since concatenating two strings is much more expensive than an multiply and an add. You can't possibly think 100 million files is a limit anyone will ever hit. :) To solve the NFS problem, we can consider NFS mounts the way we do other removable media. Create a "shares" type where the name field refers to the server:/path. That way shares can be root objects that can be considered removable. If the share isn't mounted, queries won't return objects under the share. > Maybe I can't. It sounds strange, but sometimes it is much easier to > do stuff later. Maybe a searchable attribute can't be auto invalid. It's not really avoidable that attributes will be invalidated if you allow other applications to share the same vfs. So if you don't handle invalidated attributes right away, then you'll have to accept that queries could potentially return wrong results. I don't see a way around that. Jason.
signature.asc
Description: This is a digitally signed message part