flint@gistdev.UUCP (05/26/89)
While I agree with that principle (that the network is invisible, so why
should you care where the file is), unfortunately, some aspects of networks
aren't yet advanced enough to let you assume the network is invisible, because
it isn't. To cite just one example, file locking on SYSV under RFS: the locks
for a file that exists physically on machine A are kept track of by machine A,
and not by anybody else. The result is (or at least was, in the first RFS we
received) that you can reach a deadlock situtation where the lockf(3C) call
won't return EDEADLK. (Because it checks the table on the current machine
for deadlock, but does not examine all tables on all machines.)
Our applications, in order to protect their butts, were forced to follow
one of the following rules religiously:
1. Never lock more than one file at once. (Often impossible.)
or
2. Always be sure that all the files you have locked physically reside on the
same machine. (Then all your locks would be in the same table and the
lockf call could detect potential deadlocks for you.)
or
3. Never use patient locks (F_LOCK) that put you to sleep if the file is
locked: do your own loop to try a few times with F_TLOCK and intervening
sleeps, and then after 3 or 4 tries, assume you're in a deadlock situtation.
(Even though you might not actually be deadlocked.)
Quite apart from that, I suspect that someone has found an application where
their response time could be significantly enhanced if they could recognize
that a remote file should be copied to a temporary file on the same machine
first. (ie, shipping the file across the network as one huge piece is going
to be a lot faster than asking for it in 10,000 tiny pieces. We have some
relational database software where the response time goes down the sewer if
the database isn't on the same machine in the network.)
Flint Pellett, Global Information Systems Technology, Inc.
1800 Woodfield Drive, Savoy, IL 61874 (217) 352-1165
INTERNET: flint%gistdev@uxc.cso.uiuc.edu
UUCP: {uunet,pur-ee,convex}!uiucuxc!gistdev!flint