lkml.org 
[lkml]   [2002]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [BUG] symlink problem with knfsd and reiserfs
    Date
    On Tuesday, 15. January 2002 17:47, Nikita Danilov wrote:
    > 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.

    Except it's in 3.5 format, which requires one deletion then?

    > 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.

    Bad luck for me, obviously :-(

    <4>reiserfs: checking transaction log (device 03:09) ...
    <4>Using r5 hash to sort names
    <4>reiserfs: using 3.5.x disk format
    <4>ReiserFS version 3.6.25
    <4>reiserfs: checking transaction log (device 03:08) ...
    <4>Using r5 hash to sort names
    <4>reiserfs: using 3.5.x disk format
    <4>ReiserFS version 3.6.25
    <4>reiserfs: checking transaction log (device 03:06) ...
    <4>Using r5 hash to sort names
    <4>reiserfs: using 3.5.x disk format
    <4>ReiserFS version 3.6.25
    <4>reiserfs: checking transaction log (device 03:07) ...
    <4>Using r5 hash to sort names
    <4>reiserfs: using 3.5.x disk format
    <4>ReiserFS version 3.6.25
    <4>reiserfs: checking transaction log (device 03:0a) ...
    <4>Using r5 hash to sort names
    <4>reiserfs: using 3.5.x disk format
    <4>ReiserFS version 3.6.25
    <4>reiserfs: checking transaction log (device 21:02) ...
    <4>Using r5 hash to sort names
    <4>reiserfs: using 3.5.x disk format
    <4>ReiserFS version 3.6.25

    We're talking about 100 GB on _this_ server.

    How big is the chance to loose data with -o conv?

    Is there any paper around, which describes this conversion
    a bit more detailed? If I understand you correctly, the inode
    generation counter doesn't work at all with 3.5?

    > > Cheers,
    > > Trond
    >
    > Nikita.

    Cheers,
    Hans-Peter
    -
    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:4.500 / U:25.676 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site