Subject: Re: `Large Inodes'
To: Bill Studenmund <email@example.com>
From: Johan Danielsson <firstname.lastname@example.org>
Date: 03/26/1999 19:31:15
Bill Studenmund <email@example.com> 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
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.