Given a dentry, you'd actually have to perform a "pioctl"
(AFS-specific system call) which turns into an RPC if the
item isn't already cached.
Which is too bad, since the AFS client already has the
entire FID in the internal representation of the parent directory.
On Tuesday, November 17, 1998 1:18 PM, A. Ott
[SMTP:ao@ao.morpork.shnet.org] wrote:
> ********* ***************** ********** **** ***** *****
> ************
> To subject Re: fs inode lookup
> allbery@kf8nh.apk.net (Brandon S. Allbery KF8NH) wrote:
> ********** ******************** ****** ******** *******
> *************
>
> > In message <74yA6Ko$4iB@ao.morpork.shnet.org>, A. Ott writes:
> > +-----
> > | For consistency checks in RSBAC I am looking for a way to lookup
> > | (or at
> > | least check existence of) fs inodes on devices.
> > +--->8
> >
> > Gak! RSBAC is likely to be rather incompatible with AFS in that
> > case...
> > inodes are kludged to make Unix happy; the AFS "address space" uses
> > 4-tuples
> > which are much larger than an inode number and there is no usable
> > device
> > number. Which means that inode numbers are often duplicated. I
> > recently
> > saw a bug report about Solaris ld.so, which assumes it can treat
> > device/i-number pairs as unique when it's literally impossible to
> > produce a
> > unique ID for an AFS file which will fit into a device/i-number
> > pair, so it
> > gets confused if two different shared libraries in an AFS volume
get
> > hashed
> > to the same i-number.
>
> Thanks for telling! So I will probably turn off attribute handling
for
> afs
> for the beginning, it makes not much sense anyway. Maybe I will
> internally
> use the 4-tuples later. Hopefully there will not be too many
> exceptions
> with other fs... :(
>
> How can I find these 4-tuples, given a dentry pointer? Do they fit
> into 64
> Bit, so I could simply extend inode numbers to u64?
>
> Amon.
>
> --
> Please remove second ao for E-Mail reply - no spam please!
> ## CrossPoint v3.11 ##
>
> -
> 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/
-
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/