On Wed, 15 Mar 2000, Andi Kleen wrote:
> On Wed, Mar 15, 2000 at 02:10:39PM +1100, Neil F. Brown wrote:
> >
> > As I understand reiserfs (which isn't very deeply), it has an emphasis
> > on efficient support for lots of small files, and so likes to keep
> > meta-data and some or all of the data associated with a file in the
> > directory entry that references the file.
> > I can imaging that this would mean changing the size of the file,
> > renaming the file, or even adding files to the directory could all
> > change the physical location of the meta-data on disc, making it hard
> > to have a fixed-length, stable index to a file, as needed by NFSv2,3.
>
> Reiserfs has a stable index to a file. It is currently 64bit (32 bit object
> ID + ID of the directory). Hans apparently plans to go for longer variable
Eh? Parse the last part of it, please. How the heck can it be stable upon
rename()? And how does it work with fs/reiserfs/namei.c::reiserfs_link()?
If you mean that we need ID of parent for knfsd - see our discussion on
that stuff. VFS doesn't need to know parents of non-directories.
Let me ask again:
a) is your "32 bit object ID" sufficient to
read/write/chmod/truncate/chown the file? Forget VFS, does the thing
contain enough information to do it in principle (aside of scanning the
whole tree, indeed)?
b) if you have a directory, is its "32 bit object ID" sufficient to
find ID of its parent?
c) <<---------------------------------------------------------->> to
find the entry of subdirectory with given ID?
If answer to all of those is positive - wonderful. If not - we got a
problem. If you can do it with s/32 bit/64 bit/ - not a big deal, provided
that ID is stable over rename() and depends only on file (== doesn't
depend on which link you are looking at). If you really need to know
parent to perform operations on opened file - you are _deep_ in trouble.
I assume that you _do_ support link(2) - if you don't I would really like
to know what reiserfs_link() does. As in: why it is there and what will
actually happen if you'll start calling it.
Al
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:18 EST