Re: [BUG] symlink problem with knfsd and reiserfs

[Nikita Danilov <Nikita@Namesys.COM>]

Trond Myklebust writes:
 > On Tuesday 15. January 2002 16:27, Nikita Danilov wrote:
 > 
 > > In reiserfs there is no static inode table, so we keep global generation
 > > counter in a super block which is incremented on each inode deletion,
 > > this generation is stored in the new inodes. Not that good as per-inode
 > > generation, but we cannot do better without changing disk format.
 > 
 > Am I right in assuming that you therefore cannot check that the filehandle is 
 > stale if the client presents you with the filehandle of the 'old' inode 
 > (prior to deletion)?
 > However if the client compares the 'old' and 'new' filehandle, it will find 
 > them to be different?

Sorry for being vague. Reiserfs keeps global "inode generation counter"
->s_inode_generation in a super block. This counter is incremented each
time reiserfs inode is being deleted on a disk. When new inode is
created, current value of ->s_inode_generation is stored in inode's
on-disk representation. Inode number (objectid in reiserfs parlance) is
reusable once inode was deleted. The same pair (i_ino, i_generation) can
be assigned to different inode only after ->s_inode_generation
overflows, which requires 2**32 file deletions.

So, no, reiserfs can tell stale filehandle, although not as reliable as
file systems with static inode tables.

Hans-Peter, please tell me, what reiserfs format are you using. 3.5
doesn't support NFS reliably. If you are using 3.5 you'll have to
upgrade to 3.6 format (copy data to the new file system). mount -o conv
will not eliminate this problem completely, but will make it much less
probable, so you can try this first.

 > 
 > Cheers,
 >   Trond
 > 

Nikita.