Re: Proposal: int (permission*)(struct dentry *, int)

From: Hans Reiser (
Date: Fri May 26 2000 - 11:17:04 EST

Alan Cox wrote:
> > I don't want to belabor the point, but I think you're questioning
> > the sanity not just of NFS, but also of AFS and CIFS. They
> > all use a filehandle or "fid" of some kind to identify a file
> > on the server.
> >
> > Why is insane ?
> It isnt. A lot of people look at NFS and assume since it has oddities pathnames
> are magically clean. In fact path names turn up a pile of other horrors that
> you want to avoid.
> You want pathnames for some operations and its a good way to regenerate file
> identities but you actually want a reliable file id. You want one that
> survives reboots, logical volume management changes, HA multi-pathing,
> volume relocation, ...
> Our NFS one survives some but not all of that now.
> Alan

When I started reiserfs I was sure that lifetime immutable objectids, with no
semantics contaminating them with any need to change with semantic changes, or
causing them to bloat, or causing them to need to be changed with any operation
other than delete/create, were the way to go, and they should be made to form
the core and most efficient lookup in the file system.

I lost that argument. Here is why.

You cannot have lifetime immutable ids without adding a random I/O should the
file's location change. If you cannot move files around you miss out on a lot
of optimizations. If you are acting on files in batches of several files per
disk seek, adding a random I/O is a significant performance loss.

ReiserFS currently does have lifetime immutable objectids (we call them keys)
since we currently don't change keys after they are used, but we want our
repacker (not yet written) to change that. It is a problem that if we someday
write the repacker to change the key, there exists no mechanism for letting VFS
know that it has changed.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:14 EST