lkml.org 
[lkml]   [2002]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [BUG] symlink problem with knfsd and reiserfs
    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.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:23    [W:3.118 / U:1.380 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site