Messages in this thread | | | From | Hans-Peter Jansen <> | Subject | Re: [BUG] symlink problem with knfsd and reiserfs | Date | Tue, 15 Jan 2002 17:31:58 +0100 |
| |
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/
| |