Messages in this thread | | | From | Hans-Peter Jansen <> | Subject | Re: [BUG] symlink problem with knfsd and reiserfs | Date | Tue, 15 Jan 2002 19:14:19 +0100 |
| |
On Tuesday, 15. January 2002 18:53, Nikita Danilov wrote: > Hans-Peter Jansen writes: > > On Tuesday, 15. January 2002 17:47, Nikita Danilov wrote: > > 3.6. is advantageous because of many other things, like LFS, etc. > > > How big is the chance to loose data with -o conv? > > There were problems with -o conv and remount (for root file system), but > they were cured in latest Marcelo's kernels. > > > 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? > > After file system is mounted with -o conv, all new files will be created > in a new format. This file system will then no longer be mountable as > 3.5 (and thus, inaccessible from 2.2 kernels). > > New files will store generation counters. The possibility of a stale > handle lurking undetected is when old-format file was deleted, its > objectid was reused for new format file, and super-block generation > counter at that time happens to coincide with objectid of parent > directory of the old file. Not exactly likely thing to happen, but > still.
I will meditate over the last paragraph later. I decided to follow your first advice...
I think, this is worth a note in the reiserfs-FAQ. And remember: allmost all linux distributions will use 3.5 to ensure backward compatibility.
Also note, that web man page and mkreiserfs -h disagree on the -v option. I will believe mkreiserfs.
If I use notail mount option on a already populated partition, what happens to the "tailed" files? I expect, only newly created ones get there own block.
> > 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/
| |