From owner-freebsd-current Mon Jul 15 02:21:51 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA20784 for current-outgoing; Mon, 15 Jul 1996 02:21:51 -0700 (PDT) Received: from proxy.siemens.at (proxy.siemens.at [192.138.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id CAA20750; Mon, 15 Jul 1996 02:21:31 -0700 (PDT) Received: from sol1.gud.siemens.co.at (sol-f.gud.siemens-austria) by proxy.siemens.at with SMTP id AA28633 (5.67a/IDA-1.5); Mon, 15 Jul 1996 11:20:51 +0200 Received: from ws2301.gud.siemens.co.at by sol1.gud.siemens.co.at with smtp (Smail3.1.28.1 #7 for ) id m0ufjpi-00021UC; Mon, 15 Jul 96 11:20 MET DST Received: by ws2301.gud.siemens.co.at (1.37.109.16/1.37) id AA254952338; Mon, 15 Jul 1996 11:18:58 +0200 From: "Hr.Ladavac" Message-Id: <199607150918.AA254952338@ws2301.gud.siemens.co.at> Subject: Re: strangest weirdness To: adam@veda.is (Adam David) Date: Mon, 15 Jul 1996 11:18:58 +0200 (MESZ) Cc: freebsd-current@freebsd.org, freebsd-fs@freebsd.org In-Reply-To: <199607130027.AAA07477@veda.is> from "Adam David" at Jul 13, 96 00:27:54 am X-Mailer: ELM [version 2.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In his e-mail Adam David wrote: > Well I have just seen what seems to be an unusual filesystem glitch. > I was doing 'make depend' in 2 kernel directories concurrently, and at the > same time as another kernel 'make all' was getting towards the end of its > processing. Both instances of 'make depend' broke by invoking the editor > 'ex' on an empty temporary file, following the first invocation of 'mkdep'. > No other instances of 'ex' were running at the time as far as I can tell. > > This was with an NFS /usr, and I believe that the 'make' executable was > reinstalled after the 'make all' was started but before the 'make depend' > was started. (yes, it's called stress testing. ;) > > I have also noticed that executables dump core often on client machines when > the files on the fileserver have been updated "under their feet". Okay I know > "if it hurts, don't do that", but why do these glitches occur? Well, to cut the long story short, that's sadly the way NFS works. Namely, executable is being paged in from the server. If you change the executable file between (or during) pages, who knows what will be read. Nonsense, most likely :( This does not happen on non-NFS mounted volumes (read: local) since then the ETXTBUSY is returned to the potential writer. Alas, NFS server does not know what is being done to the file it serves (i.e. it does not know that it's actually being executed, rather than just randomly read.) A possible workaround would be commiting all nfs mounted executables to swap, but to the best of my knowledge nobody does that (yes, the big commercial boys suffer from the same illness.) Terry will probably correct me :) /Marino > > -- > Adam David >