Hi,
The note below from Craig and other mails on info-afs have hit on
what is currently a soft spot for us: 3rd party SW vendor support
of AFS.
Have you ever encoutered the situation in which:
sysadmin: "we shall move all your data to a new filesystem tomorrow.
its faster, more reliable, more secure, etc..."
user/customer: "Great, but wait... does the XXXYYYZZZ SW from aaabbccc
company support it?"
sysadmin: "well,.. not officially, but we have tested it here and there
seem to be no problem with it".
user/customer: "I believe you, but what if in their next release we
stumble on something, who will be responsible?".
etc, etc.
There are not very many companies out there that claim in their data
sheets that their support AFS, yet I bet 90% of SW packages do run
in an AFS environment with little or no problem. The questions are:
1. what do you do with the remaining 10% ?
but much more important,
2. how do you make your user/customer environment feel 100% confident
that they are not taking any risks? (remember, they dont care
much about filesystems.... ;-)
comments are welcome.
-- Igal Iancu
IDC/CBS
Yield & Planning
Intel Israel (74), Ltd.
POB 1659 Haifa 31015, Israel
[EMAIL PROTECTED]
Tel: 972-4-655869
Fax: 972-4-655999
> The question is probably what network ports Pro/PDM??? uses. AFS uses
> ports in the 7000-7010 range, most likely 7000, 7001, and 7003 in the
> cache manager itself. If their product is trying to use those ports as
> well for their RPCs, then things could well be screwed up. There has to
> be a way to keep their RPCs from using those port numbers, but that will
> depend on what they're doing to select port numbers for their RPC
> programs. And it might, or might not, be tough to change the PTC
> products not to use colliding port numbers.
>
> As far as other problems, there are the standard issues of AFS not
> observing the mode bits for Unix protections, AFS groups not being the
> same as Unix groups, byte-range locking not being supported,
> non-``standard'' (non-automounter) semantics for mount points,
> non-cheapness of stat()'ing every file in the /afs/ directory, slightly
> different st_dev/st_rdev/st_fsid results, AFS files not being stored
> back on a server until close() or fsync(), the fact that close() can
> return error codes, and that codes such as ETIMEDOUT might be returned
> from syscalls whose callers don't expect it. Other than that, and
> whatever else I've forgotten, there shouldn't be much of a problem.
>
> Craig
