QUESTION:
We are just beginning to work with NFS. To do some initial testing,
we created an NFS filesystem on SYS1 and mounted it on SYS2. A user
on SYS1 and a user on SYS2 both vi-edit the same filea. It appears
that, if both users then save/exit (:wq) the file, only the changes
made by the last user to save/exit are actually written to the file.
We assume this has something to do with NFS locking mechanisms *not*
being used during the concurrent vi-editing sessions. Some questions:
1) It appears from our testing that the vi-editor does *not* by default
use any form of NFS locking; i.e., both users (on SYS1 and SYS2) can
vi-edit filea at the same time, and changes made by one user will
overlay changes made by the other. Is this a correct understanding?
2) Is there any way to cause vi (or another "favorite editor") to use
NFS locking on files in an NFS-mounted filesystem, as described in the
scenario above?
3) More generally, what causes an application to place a lock on an
NFS-mounted file? Must the application use NFS "lock" and "unlock"
commands within its own logic/code, or is there some "external"
mechanism which causes NFS file locking/unlocking to occur?
4) ASKQ Item ORPL1 on "AIX NFS LOCKING" seems to imply that NFS is not
a good (not the best?) choice for an application where multiple systems
will be accessing "shared" NFS-mounted files; performance seems to be
the issue. ASKQ ORPL1 suggests using a distributed database product
for this requirement. Would you agree? If so, what is an appropriate
use of NFS? For "read only" shared data?
Thanks for your help and counsel on these issues.
---------- ---------- ---------- --------- ---------- ----------
A: I will answer your questions in the order asked.
1) You are correct, vi does not use any form of NFS locking.
When you use vi to edit a file, the file is copied to the
local /tmp directory to be worked on. Then when you write
the file, it is copied from /tmp to its original location.
Therefore, if two NFS users are simultaneously using vi to
edit a file, there are actually three copies of the file -
one original, one in /tmp of usr1, one in /tmp of usr2. The
last copy of the file written back to its original location
is the state which the file will remain in until edited
again.
2) There are no text editors, that I know of, that use NFS
file locking. Perhaps you could use a high-level editor,
that performs file locking, then export it to text. This
would prove cumbersome.
3) The only time NFS performs a file lock is when the code of
a program calls for a lock, or if a second data stream is
attempted to be opened on a file.
4) I don't particularly agree. I haven't notice significant
performance problems with NFS read-write filesystems. NFS
lacks a little in data integrity, but only during network
crashes - you may loose a write or two. Nothing that
significant, especially if you're only doing text editing.
The following is a program that performs a NFS lock and unlock
on a file. This program IS NOT supported or endorsed by IBM.
I am providing you with this code - on a test basis only. I
cannot help you debug this code, or any code you may produce
using its techniques.
___________________________________________________________________
FYI:
There is an undocumented flag (-d) which causes the daemon to send
debugging information to stdout. I reported this to Software Services
(PMR 9X484) as a documentation defect, but was told that it will not be
documented. The developer put the flag in for his own use, not for
general use. In any case, to see the debugging information, use the
syntax:
/usr/etc/rpc.lockd -d5 >/tmp/lockd.out 2>&1 &
___________________________________________________________________
/* THIS PROGRAM LOCKS, WAITS 30s THEN UNLOCKS */
/*
File: locktest.c
Author: Darin Davis
Date: 15 April 1994
Desc: A simple program to lock a file. Written to
experiment with the NFS rpc.lockd daemon.
Compile: cc -o locktest locktest.c
Usage: locktest
*/
#include
#include
#include
#include
#define DREAM 30 /* how long to sleep */
main( int argc, char *argv.. )
int fd, /* file descriptor */
rc;
/* check command line parms */
if (argc < 2) {
printf(" s: file_to_lock\n", argv.0.);
exit(1);
}
/* open the file */
if ((fd = open(argv.1., O_RDWR, 0)) == -1) {
printf("Couldn't open ' s' read/write.\n", argv.1.);
exit(1);
}
else printf("Opened ' s' as fd d.\n", argv.1., fd);
/* lock the file */
if ((rc = lockf(fd, F_TLOCK, 0)) == -1) {
printf("Couldn't lock fd d.\n", fd);
close(fd);
exit(1);
}
else printf("Locked fd d.\n", fd);
printf("Going to sleep for d seconds...\n", DREAM);
sleep(DREAM);
printf("Just woke up.\n");
lockf(fd, F_ULOCK, 0); /* unlock the file */
printf("Unlocked fd d.\n", fd);
close(fd); /* close the file */
printf("Closed fd d.\n", fd);
exit(0);
________________________________________________________________
Thank You.
---------- ---------- ---------- --------- ---------- ----------
This item was created from library item Q673634 FDNSJ
Additional search words:
AIX AUTO AUTOMATIC BASE COMMUN COMMUNICATIO CONCERNING DATA DATABASE
DISTR DISTRIBUTED FDNSJ FILE FILES IX LOCKING NFS OCT94 OZIBM OZNEW
QUESTION RISC RISCOC RISCSYSTEM RS SHARE SOFTWARE 6000
WWQA: ITEM: RTA000050275 ITEM: RTA000050275
Dated: 01/1996 Category: RISCOC
This HTML file was generated 99/06/24~12:43:19
Comments or suggestions?
Contact us