From owner-freebsd-hackers Fri Feb 10 17:56:14 1995 Return-Path: hackers-owner Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id RAA19059 for hackers-outgoing; Fri, 10 Feb 1995 17:56:14 -0800 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id RAA19053 for ; Fri, 10 Feb 1995 17:56:12 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA14264; Fri, 10 Feb 95 18:49:46 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9502110149.AA14264@cs.weber.edu> Subject: Re: MIT SHM X11 extensions? (fwd) To: peter@bonkers.taronga.com (Peter da Silva) Date: Fri, 10 Feb 95 18:49:45 MST Cc: davidg@Root.COM, jmb@kryten.atinc.com, hackers@FreeBSD.org In-Reply-To: <199502110003.SAA23105@bonkers.taronga.com> from "Peter da Silva" at Feb 10, 95 06:03:35 pm X-Mailer: ELM [version 2.4dev PL52] Sender: hackers-owner@FreeBSD.org Precedence: bulk > > Actually, you could fault the whole image to swap and close the > > reference to the file -- and just allow the write, with never an > > ETXTBUSY to be seen. > > I consider the sudden explosion of swap utilization to be a surprising > consequence, especially considering the size of some images. When you're > writing to an image you're likely replacing it with "install" anyway. > Let "install" detect the ETXTBSY and do a little shuffle. Mount /usr over NFS and run apps from it from the an NFS client. Then while these apps are running, update the server /usr/bin. I consider the sudden explosion of core files on the client to be an even more suprising consequence, especially sonsidering that you can largely ignore swap unless you actually run out. Realistically, you could watermark it and start randomly crashing things at 90% swap utilization on the client instead of putting up "out of swap messages. Of course one can react to messages, whereas one can only clean up after core files. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.