shared libs in AFS

[Magnus Ahltorp]

> When arla is first started on the machine, all is well, and we can
> see and load the libraries.  After a time (few hours or so), an odd
> thing happens - I can still ls each of the shared libraries, I can
> cat each of them to /dev/null, and I can cp each out of AFS.  If I
> retrieve one of the libraries from AFS by way of a different machine
> running Transarc's AFS and compare it to one retrieved using arla
> they seem to be byte for byte identical.  However, running ldd on
> our main application reports that some of the shared libraries can't
> be found.

This may well be an arla problem. I haven't dug into the problem with
reference counts when mapping files. It should work, but I have never
done any tests to investigate if it does. I will try some experiments,
and I will come back with results.

It does look like a problem where a file has been thrown away by arla
and can be seen in the normal ways but an old bogus copy is still
referenced somewhere. It could be a linux problem, but I would not say
that it is before I have eliminated all arla suspicions.

> If anyone has tips on how I could diagnose the problem, how I could
> collect good debug info or something, I'd be very grateful.

These are not things I expect you to do, but if any of this feels like
something you (or anyone else) would be able to do, I would be most
grateful:

1) Debugging the dynamic linking process to find out what data it
really looks at would be most helpful, but I don't have the slightest
clue as to how this might be done. strace might work when doing ldd,
but then you won't catch the memory accesses.

2) A behaviour analysis of the whole system when this happens. xfs
debugging might help here. The key points are when xfs_d_delete is
called (especially when it says "no references, tell arlad") and when
a new file is requested through xfs calling arlad with "getdata" and
arlad responds with "installdata".

/Magnus
map at stacken.kth.se