lkml.org 
[lkml]   [2000]   [Mar]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: (reiserfs) reiserfs and knfsd and NFSv4 and volatile file handles
Alexander Viro wrote:
>
> 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()?

Not sure I understand your question, but I'll take a stab at it. Currently the
first directory a file is created in stays its packing locality parent for the
life of the file. The packing locality parent is the first key component. So,
currently, if you know the parent directory id the file was created in you know
the first component of the key, and the last component of the key is the offset
which you can also know. This leaves the middle of the key unknown.

The immutability of keys is true merely because we don't yet have a repacker to
do re-optimize once a day, and it will change, but for now it is true. The
first version of our repacker probably won't change keys, but clearly it should
eventually have that functionality.

The notion that keys/objectids should be immutable over the life of the object
is a notion I once believed in but have since conceded was wrong of me.

So, if you create a file in one directory and then access from another
directory, we are as inefficient as using conventional inodes. At least until
the repacker that has not yet been authored gets written by us....

>
> 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)?
No, we need the directory id plus the objectid (plus the offset) to know what
the key is.
> b) if you have a directory, is its "32 bit object ID" sufficient to
> find ID of its parent?

directories are their own parents as far as constructing keys is concerned in
plan A which is our next version, key construction for the current version puts
directories in the parent of the directory which is an ~10% performance losing
notion of a former project member, sigh. If 2.4 had been another month or two
out we would have fixed it, such is life.... it will wait for 2.6.

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

If you know the parent it was created in you know the first 32 bits and only
need to know another 32 (plus the offset in the file). Otherwise you need 64
bits plus the offset. Note that we already have potential sponsors saying that
4 billion files isn't enough, and that they need more bits for objectids.

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

link works.:-) I think I explained the difficult part above, if you need more
detail ask.

> Al

Hans
--
You can get ReiserFS at http://devlinux.org/namesys, and customizations and
industrial grade support at reiser@idiom.com.

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

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