Subject: Re: RFC: new mode bits in stat structure
To: None <tech-kern@NetBSD.ORG>
From: Ty Sarna <email@example.com>
Date: 06/26/1998 17:52:31
In article <199806261424.KAA00726@road-runner.mit.edu>,
Nathan J. Williams <nathanw@MIT.EDU> wrote:
> > - File is not resident on disk
> It feels a little bit weird to use flags for these. I think
> that's because they seem like part of the internal implementation of a
> filesystem (the HSM), but the interface to them is exposed to
> userspace. What happens to my HSM system if I start using chflags(2)
Except that the implementation is in userspace. I'm assuming that the system
Jason is talking about is essentially similar to what we talked about on
tech-kern previously. It's implemented as a vfs layer that mounts over a
cache directory and communicates with a daemon process to handle
bringing files in from storage.
> to frob these bits? If I turn off the "File is not resident" bit, what
> do I get when I read the file? Or, if I'm writing a backup utility, I
Turn off the bit on which file? The top layer, or the bottom layer?
In the bottom layer, you presumably just cause the next access to the
file to bring in the file and mark it resident again. On the top layer,
either it's a no-op, or maybe a hint to the daemon that the file is no
longer desired and can be migrated out.
> might grab the stat structure and then the file - but reading the file
> will cause the stat structure to become invalid. If I then write back
> the same information, I will have a existing file with the
> non-resident bit set, which is bizzare.
The top layer would ensure that the bits represented the actual state of
things. In the bottom layer, they are used for bookeeping.