On Fri, 26 Mar 1999, Roger Brooks wrote:

> On 26 Mar 1999, Chris G. Demetriou wrote:
> 
> >Naively, in thinking about the problems inherent in handling large
> >data sets/files and data migration to/from tape, i'd think that an
> >extra local file lookup ... would not be your performance bottleneck.
> 
> No, I'm afraid this isn't so.  The point about a filestore with automatic
> data migration is that within any directory, some files are in the
> upper layer while others are in the lower layer (in this case on tape).
> But when you type 'ls -l' you see all the information about the files in
> both layers (without having to drag anything off the tape).  Only when you
> try to read (or modify) a file which has migrated to tape do you need to
> retrieve it.  This really means that all the inodes have to live in the
> upper layer all the time.

Exactly. The per-file extra info will get used a lot more often than the
per file. 'ls -l' is the canonical demo. :-)

> The first computer I worked on (about 22 years ago) was an ICL 1906S
> running GEORGE 4.  This had a data migration filestore which was very
> advanced for its time, considering that it used 1/2" tapes which had
> to be loaded by operators.  The tape layer was also the filesystem
> backup, which consisted of rolling increments (with all the tapes
> duplicated).  Once a file had been backed up in a increment it became
> a candidate to be thrown offline (depending on size and free space).
> But AFAIR, with GEORGE you could even do the equivalent of a chmod on
> an offline file without retrieving it from tape because the equivalent
> of the inode was always on disk.

Our system is a little different - we never blow away the file, just its
data. So each file always has an inode, and has 0 length. That's why a
larger inode would have been cool. :-)

> Interesting question: when the data migrates to/from tape, should
> the ctime change?  After all, you haven't changed any of the other
> fields in the data you would get back from stat(2).  

Probably not.

Take care,

Bill