Bill Studenmund <wrstuden@nas.nasa.gov> writes:

> 2) In a seperate stream off of the file, a la MacOS resource forks or
> NTFS's ability to store restoures forks. My concern with our application
> using this is the cleanest way I've thought of to impliment it in ufs is
> to make one file's inode refer to another inode, which would hold that
> fork's data. On the current systems we have, we already have to crank up
> the number of inodes in the fs just to hold what we have. We have fs's
> with about 10 million inodes on them. If we have to have two inodes per
> file, it's even worse.

> Can you think of anywhere else we can store the data?

There are spare fields in the inode; you can use one of them as a
pointer to this data (you don't need a whole inode). Digital UNIX uses
something like this to store whatever you like, one (and the only I
know of) application is for acl:s. These extra blocks are treated as
meta data.

If you plan to store lots of data this won't scale (since it's a
linked list), but that's not really what you'd want to do.

/Johan