[reiserfs-list] RE: [OpenAFS-devel] weird issue with reiserfs on 2.4.3 and openaf s

[Neulinger, Nathan]

> > If so, perhaps when we initiate the cache file we can
> > check if it's reiserfs and, if so, open the inode (which is 
> currently
> > in the cache), grab the extra data, save the extra data (somewhere),
> > and then release it.  Then, later, we can check the saved data and
> > notice that the file was reiserfs and behave specially.
> > 
> > I really don't like this solution.. It's a complete kludge and
> > special-case for reiserfs..  But I think it would solve our problem
> > until, as you say, we move to 64-bit inodes :)
> > 
> 
> This is what I had in mind.  Where would we store the extra 
> stuff in AFS?

The in-kernel stuff that keeps track of the inode numbers for the cache file
will need modified to keep track of additional stuff. 

So, presuming you can get me code to obtain that extra bit of information, I
can work on adding the code to the afs kernel module to keep track of it.
Once that is done, we can have add the code to use iget4.

Is iget4() something standardized? I.e. will it be as simple as:

	if ( functionality_exists(iget4) )
	{
		extra = retrieve_extra_from_afs_internals(inum);
		if ( extra_found )
		{
			inode = iget4(sb,inum,extra);
		}
		else
		{
			inode = iget(sb,inum);
		}
	}
	else
	{
		iget(sb,inum);
	}

(I haven't seen iget4, and obvioulsy above calls are bogus, cause they only
have three args, but you get the idea.)

-- Nathan