chip@tct.com (Chip Salzenberg) (04/19/91)
I sent Rahul mail on this subject some time ago, but he seems not to have received it; thus this article debunking his locking "solution". According to Rahul Dhesi <dhesi@cirrus.COM>: >The usual technique for locking with a lock file ... The ... problem >is that exclusive creates do not work over NFS. Solution follows. > >int get_a_lock() >{ > if (create(symlink called MUTEX that points anywhere) == failed) { > die("serious problem -- can't create MUTEX"); > } This "solution" is nothing of the kind. NFS can report failure on a symlink creation (or on directory creation) even if the operation succeeds. Any locking protocol that depends on the return code of symlink or directory creation is not robust over NFS. NFS's statelessness is supposed to be a feature. Well, as far as I'm concerned, the designers of NFS can go take a flying leap, and they can take their stateless protocol with them. -- Brand X Industries Custodial, Refurbishing and Containment Service: When You Never, Ever Want To See It Again [tm] Chip Salzenberg <chip@tct.com>, <uunet!pdn!tct!chip>
thurlow@convex.com (Robert Thurlow) (04/20/91)
In <280EE8A1.30D@tct.com> chip@tct.com (Chip Salzenberg) writes: >NFS's statelessness is supposed to be a feature. Well, as far as I'm >concerned, the designers of NFS can go take a flying leap, and they >can take their stateless protocol with them. C'mon Chip, flame in the right direction. The lack of support for O_EXCL in the create operation of NFS isn't a feature of statelessness, it's just a simple-minded protocol bug. If Sun would get off its cans and tell us the way a new protocol revision carried this information, all of us vendors could add support in ten minutes. But you can go ahead and flame Sun for the protocol bug and the time they've let go by on addressing it. Rob T -- Rob Thurlow, thurlow@convex.com An employee and not a spokesman for Convex Computer Corp., Dallas, TX
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (04/20/91)
In <280EE8A1.30D@tct.com> chip@tct.com (Chip Salzenberg) writes: >This "solution" is nothing of the kind. >NFS can report failure on a symlink creation (or on directory >creation) even if the operation succeeds. How about calling it "the closest thing to a solution that has yet been seen on Usenet"? I seem to remember an email message from you to which I sent a brief reply of thanks; perhaps my reply failed somewhere. (Hmmm....maybe your mail software uses symlinks for locking, and the lock failed, so you never got my reply :-) -- Rahul Dhesi <dhesi@cirrus.COM> UUCP: oliveb!cirrusl!dhesi
kyle@uunet.UU.NET (Kyle Jones) (04/21/91)
chip@tct.com (Chip Salzenberg) writes about Rahul Dhesi's code: > This "solution" is nothing of the kind. > > NFS can report failure on a symlink creation (or on directory > creation) even if the operation succeeds. Any locking protocol that > depends on the return code of symlink or directory creation is not > robust over NFS. True, but using symlinks could be a start toward a solution. Instead of creating symlink pointing to a random place, why not put your hostname and process ID into the symlink? Then you could use readlink() to read the information back from the symlink and verify that it is your lock. This beats link() because you get a file creation _and_ one atomic write which you can use for identification purposes. > NFS's statelessness is supposed to be a feature. Well, as far as I'm > concerned, the designers of NFS can go take a flying leap, and they > can take their stateless protocol with them. No argument here. kyle jones <kyle@uunet.uu.net> ...!uunet!kyle Oh, yeah, that was that package that I was having so much trouble installing. There was a combination of things going wrong, and to make the story short, someone should go back in time and shoot the person who invented NFS. And then bugger the corpse. - one very unhappy system administrator
chip@tct.com (Chip Salzenberg) (04/22/91)
According to Rahul Dhesi <dhesi@cirrus.COM>: >In <280EE8A1.30D@tct.com> chip@tct.com (Chip Salzenberg) writes: >>This "solution" is nothing of the kind. >>NFS can report failure on a symlink creation (or on directory >>creation) even if the operation succeeds. > >How about calling it "the closest thing to a solution that has yet been >seen on Usenet"? I would agree with that assessment, as long as it were followed by the disclaimer, "but then, 'almost solved' means 'not solved.'" If I had a Sun machine, I'd avoid NFS-mounted mailboxes like the plague. (I'd shun cliches, too; but that's another story.) >I seem to remember an email message from you to which I sent a brief >reply of thanks; perhaps my reply failed somewhere. (Hmmm....maybe >your mail software uses symlinks for locking, and the lock failed, so >you never got my reply :-) Well, I apologize if I ruffled any feathers. What really sets me off is when a vendor creates a problem for which no reasonable workaround exists, and then lets it endure for a long time. Sun's motto should be: "Our Lockd Matches Our NFS Protocol: They're Both Broken". -- Brand X Industries Custodial, Refurbishing and Containment Service: When You Never, Ever Want To See It Again [tm] Chip Salzenberg <chip@tct.com>, <uunet!pdn!tct!chip>
chip@tct.com (Chip Salzenberg) (04/22/91)
According to thurlow@convex.com (Robert Thurlow): >C'mon Chip, flame in the right direction. The lack of support for >O_EXCL in the create operation of NFS isn't a feature of statelessness, >it's just a simple-minded protocol bug. I don't understand. How can the server know that it's me re-requesting an already-successful creation, and not some other process on the client machine asking to create the same file? (Please note that solutions based on keeping transaction info for the last N seconds are NOT acceptable, as the network cable might be disconnected for N+1 seconds.) -- Brand X Industries Custodial, Refurbishing and Containment Service: When You Never, Ever Want To See It Again [tm] Chip Salzenberg <chip@tct.com>, <uunet!pdn!tct!chip>
les@chinet.chi.il.us (Leslie Mikesell) (04/23/91)
In article <3074@cirrusl.UUCP> Rahul Dhesi <dhesi@cirrus.COM> writes: >In <280EE8A1.30D@tct.com> chip@tct.com (Chip Salzenberg) writes: >>This "solution" is nothing of the kind. >>NFS can report failure on a symlink creation (or on directory >>creation) even if the operation succeeds. >How about calling it "the closest thing to a solution that has yet been >seen on Usenet"? There is some discussion in comp.unix.shell about using (umask 777; echo >file) || .... failure code... as an attempt to get a more or less atomic operation in spite of NFS, but I don't see how it can work if you run as root. Les Mikesell les@chinet.chi.il.us
bmw@isgtec.uucp (Bruce M. Walker) (04/24/91)
In article <28123DD5.1716@tct.com> chip@tct.com (Chip Salzenberg) writes: > If I had a Sun machine, I'd avoid NFS-mounted mailboxes like the > plague. Well, my site demands centralized mailboxes. How would you suggest I do this without NFS? - I am aware of POP[23]/PCMAIL/IMAP: we use elm, ucbMail and mh. Only mh supports one of these (POP2). - We have Sun4's, SGI's, DECstations, an IBM RS6000 and Convergent Tech's. Can one of these do a better job of being a mail-host? -- "Remember, only *you* can prevent emacs!" bmw@isgtec.uucp [ ..uunet!utai!lsuc!isgtec!bmw ] Bruce Walker