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.

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to