[reformatted]
On Mon, 26 Jun 2000, Michael W Zappe wrote:
[snip]
> filesystem, CXFS. (originally named Charon, but we discovered two
> companies warring over the trademark, and didn't want to touch that with
> a 40 foot pole... ;-)
Heh. XFS folks mentioned clustered variant of their puppy. Yup, also
CXFS...
> But in terms of the VFS problems, I have to say that your idea is a good
> one, since it keeps the data local to the inode! The only issue i'd
>have with it is the way you do the define. I think a much cleaner
>solution would be to have each fs define a structure
>
> struct ext2_inode
> {
> struct inode ei_inode;
> struct ext2_inode_info ei_ext2_info;
> };
>
> And just clean up all of the other filesystems to use a more generic
>mechanism to cast it, such as:
>
> #define EXT2_INODE_INFO(inode) (((struct ext2_inode *)(inode))->ei_ext2_info)
Umm... I don't like how it sounds. Basically, it means that iget() goes
to hell - that way allocation has to be done in fs. May be a good thing,
but we are not there yet.
> This would also mean that if anything changed, we have an inexpensive
> (non-existent at runtime) level of abstraction which would allow for a
> simple change. I also use a similar mechanism, and it works great for
> portability. I'd definately be willing to help clean up the FS code to
> use the new interface.
Could you describe that new interface in some details? I don't see how you
deal with knfsd and with allocation/freeing policy. Another thing to watch
for: init_once()-type animals.
> I also wouldn't mind adding changing the iget code to a new iget2 which
> takes an opaque, fs dependent parameter (void *). We would also split
Not funny. First of all, you have to deal with callers in knfsd. If we
kill them (fh<->dentry patches) there is no reason to keep iget() and
->read_inode() at all. Otherwise... Where the heck will knfsd get your
void * cookie?
> the functions into
>
> void read_inode(struct inode *, void *);
> void get_inode(struct inode *, void *);
>
> Read inode is called only on an uninitialized inode structure, and
> get_inode whenever iget pulls an inode out of the cache. This way, if
> the FS isn't concerned with additional reads after the first, the
> pointer can just be NULL and we optimize out the call.
??? That's something new - which filesystems need to do reread upon the
icache hit?
> Also, i wouldn't mind changing i_ino to be a __u64. Anyone see any
> major problems with this? We'd have to change the hashing code, (which
> wouldn't be a bad idea anyway) but i think most everything else will
> convert fairly cleanly. I have to look at this change a little more
> closely, but it seems to be a good idea.
No problem, except that you are getting an overhead on comparisons in the
cache. My gut feeling is that it's not going to be critical, but there's
only one way to figure out... Keep in mind that x86 is register-starved,
so anything 64-bit is a strain on compiler. I suspect that it may turn
into worse overhead than anything coming from separate allocation of
per-fs part.
