> In some email I received from Jason Thorpe, sie wrote:
> [...]
> > I'd like to add these new bits and the changes to the system utilities that
> > would care about them to the master NetBSD sources (not only does this save
> > hair for us, but we are hoping to fold all of the HSM code back into NetBSD
> > at some point).  Are there any objections to this?
> 
> Hmm.  You're using up bits from a limited resource, and whats more, it is
> the last two bits available.  If possible, I'd *really* like to see it
> somehow use only 1 bit and then use a combination of bits (if needed) to
> achieve your goal.
> 
> The first, one, S_ISARCHIVED, I'm fine with.
> 
> #define	S_IFARCHIVED	0200000		/* file is archived */

This fine for me too.

> However, this one, I'm not so sure about:
> #define	S_IFNONRES	0400000		/* file is non-resident */
> 
> To me, this is a variation on the above (but it is archived, right ?).
> 
> What if it's used in conjuction with a bit from flags or use flags instead
> of mode ?

I would let the HSM VFS module to manage this information internally
(e.g. in one database file). It is no use for normal filesystems
and for special things like HSM you will always need additional special
attributes that would unnecessarily pollute the interface and you would run
out of spare bits very soon  if handled this way.

The problem of "ls" display can be handled in general and elegant manner
using fs-specific "ls plugins" (see /usr/lib/fs/ on Solaris or mount_* and
fsck_* families). The overhead would be only one dlopen() per listed
filesystem type.

-- 
Zdenek Salvet                                              salvet@ics.muni.cz 
----------------------------------------------------------------------------
           If God had meant for us to be in the Army,
         we would have been born with green, baggy skin.