Bug#143111: [OpenAFS-devel] Testing GNU findutils on AFS.... please!

[Jeffrey Hutzelman]

--On Monday, May 05, 2008 01:05:59 PM +0100 James Youngman <jay@gnu.org> 
wrote:

> On Tue, Apr 8, 2008 at 12:19 AM, Jeffrey Altman
> <jaltman@secure-endpoints.com> wrote:
>
>>  Are you willing to attempt to try to perform an AFS pioctl call
>>  to verify if the path is in AFS?
>
> Speculatively for every directory on every system, no.

It shouldn't be necessary for every directory, only for the first directory 
and every time you cross into a new filesystem (i.e. st_dev changes).

> It occurs to me to ask something else though.  Is possible for there
> to be any kind of infinite cycle in an AFS directory hierarchy?

Yes.  Any number of mount points can refer to a volume, and it is possible 
to construct cycles this way.

> With regular Unix filesystems we rely on the uniqueness of the
> {st_dev,st_ino} combination; if we see the same value pair twice under
> one startpoint, we conclude there is a loop.  Will this method work
> for AFS?

Mostly.  Inode numbers in AFS encode the vnode number and volume ID; 
distinct vnodes in the same cell will have distinct inode numbers unless...

(a) You have 32-bit inode numbers and more than 2^16 volumes
(b) You are one of a handful of cells with funny volume ID's
(c) You have a volume with more than 2^15 directories or 2^15 non-dirs.

In any of those cases, you might get multiple vnodes with the same inode 
number.  In addition, vnodes in different cells may have different inode 
numbers, because the inode number does not encode the cell.

In practice, we've found this to be good enough for a wide variety of uses 
that depend on inode number uniqueness, for many years.  However, for 
correctness, if you think you've encountered a loop it is probably best to 
do an AFS pioctl to discover the actual FID cell, volume ID, and vnode 
number of the potentially-duplicate entry.  Of course, this requires that 
you have done so for the first occurrance, but IMHO the performance penalty 
of making this call for every directory known to be in AFS is acceptable.


>> > Now that I think about it, it would also be helpful to know what
>> > common Linux AFS clients put in struct dirent.d_type for AFS
>> > filesystem objects (files, directories, ...).  How about other Unix
>> > systems which support both AFS and d_type?  I also understand that AFS
>> > ACLs can sometimes allow readddir() to return a directory entry
>> > without it being possible to lstat(2) said directory item.  Is this
>> > the case?   What goes into d_type for such items?
>> >
>>
>>  I will let someone else answer this.
>
> Nobody has, though, yet...

I believe I did answer this.

When we know the type, we fill it in.  Directories and mount points get
DT_DIR; files get DT_REG.  Currently symlinks always get DT_UNKNOWN, which
I consider a bug, and so do objects whose type is genuinely not known.

MacOS X uses the same logic as Linux, described above.
It doesn't look like OpenAFS supports d_type on other platforms.

Yes.  It's possible to get an entry that corresponds to a directory on
which you have no permissions, or a mount point pointing at a volume that
doesn't exist, or for a FetchData call to return an error in response to
some problem on the fileserver.

-- Jeff