Return to BSD News archive
Newsgroups: comp.unix.bsd Path: sserve!manuel!munnari.oz.au!network.ucsd.edu!sdd.hp.com!caen!hellgate.utah.edu!fcom.cc.utah.edu!park.uvcc.edu!ns.novell.com!gateway.novell.com!thisbe!terry From: terry@thisbe.npd.Novell.COM (Terry Lambert) Subject: Re: lockd on 386BSD Message-ID: <1992Aug24.171836.2450@gateway.novell.com> Sender: terry@thisbe (Terry Lambert) Nntp-Posting-Host: thisbe.eng.sandy.novell.com Organization: Novell NPD -- Sandy, UT References: <BtFxC8.3r0@chinet.chi.il.us> <1992Aug23.205117.5204@fcom.cc.utah.edu> <1992Aug24.033540.11335@ugle.unit.no> Date: Mon, 24 Aug 1992 17:18:36 GMT Lines: 79 In article <1992Aug24.033540.11335@ugle.unit.no>, arnej@Lise.Unit.NO (Arne Henrik Juul) writes: |> In article <1992Aug23.205117.5204@fcom.cc.utah.edu>, |> terry@cs.weber.edu (A Wizard of Earth C) writes: |> > In article <BtFxC8.3r0@chinet.chi.il.us> randy@chinet.chi.il.us (Randy Suess) writes: |> > > |> > > Well, still no luck in being able to ">>" (append) properly |> > > to a BSD partition NFS mounted to my Dell system. Tried all |> > > sorts of different mount options, tried different shells, etc. |> > > Append works ok on a Novell 3.11 mounted NFS partition, and another |> > > SYSVR4 (AT&T) system. Now, I have noticed that 386BSD is not |> > > running any sort of lock daemon, i.e. lockd. Not even any mention |> > > of it in any of the man pages having to do with NFS. |> > > Is this normal? |> > |> > 1) lockd is an addon. It's normal to not have it. You may want to |> > add it on, though. |> |> But you probably don't want to write it, I don't :-) |> NFS and file locking are - well - somewhat anathema. |> |> |> > 2) The append failure is not a result of NFS. It's a result of a rather |> > loose interpretation of the "a" and "a+" modes in POSIX 1003.1. You |> > would be better off fixing the shell, or you're bound to repeat the |> > performance later with some other box. |> |> I do not understand this comment - would you care to explain further? |> I have read the Standards (1003.1 and ANSI C), and they seem pretty |> clear to me. Tell me: when you implement signals according to POSIX 1003.1, and a signal handler is currently executing, what is done with subsequent signals that arrive while you are in the handler? POSIX 1003.1 has lots of ambiguities; there wouldn't be revisions to it in the works if it did not. The particular ambiguity I am referring to was discussed here before; in particular, if you open a file in append mode, the file pointer is set to the end of the file. If you seek to a different offset prior to the EOF point, the seek places the pointer at EOF, not at the requested location. In combination with the create flag, this can cause full truncation. There have been patches to the system() commands for elm and other tools to get around that problem posted in this group. |> Anyway, I will assert that it IS an NFS problem. The following |> program: [ ... How to truncate a file ... ] |> |> This is a bug *somewhere* in NFS, and the big question is: SunOS or |> 386bsd? Personally I'd bet that SunOS was the problem here, but |> that's only my gut feeling that Sun are unable to implement their own |> protocols according to spec. The fact that this does not occur on some boxes is relevant on in the mechanism they use to implement their client caching. The "problem" is in the append determination code in the UFS on 386BSD, and does not prevent 386BSD from meeting POSIX 1003.1. Therefore, although undesirable, the behaviour is "correct". This problem also occurs in the "rogue" score file code (thus bearing no relationship whether or not NFS clients use different, and, in theory, functionally equivalent, mechanisms to accomplish the same ends) and has already been discussed in this group. |> We also have nearby a box running DEC OSF v1.0, which I *think* has the |> same problem, but I am unable to test this just now. Given OSF's file system derivation, this is not suprising. I suspect this is a general BSD problem, and not limited to 386BSD. Terry Lambert terry_lambert@gateway.novell.com terry@icarus.weber.edu --- Disclaimer: Any opinions in this posting are my own and not those of my present or previous employers.