From owner-freebsd-hackers Mon May 12 03:55:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA11950 for hackers-outgoing; Mon, 12 May 1997 03:55:23 -0700 (PDT) Received: from halicore.csv.warwick.ac.uk (csubl@halicore.csv.warwick.ac.uk [137.205.148.211]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA11945 for ; Mon, 12 May 1997 03:55:05 -0700 (PDT) From: Mr M P Searle Message-Id: <985.199705121054@halicore.csv.warwick.ac.uk> Received: by halicore.csv.warwick.ac.uk id LAA00985; Mon, 12 May 1997 11:54:16 +0100 (BST) Subject: Re: shutdown In-Reply-To: from Nadav Eiron at "May 12, 97 10:53:58 am" To: nadav@cs.technion.ac.il (Nadav Eiron) Date: Mon, 12 May 1997 11:54:11 +0100 (BST) Cc: chuckr@mat.net, csubl@csv.warwick.ac.uk, hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > On Mon, 12 May 1997, Chuck Robey wrote: > > > On Sun, 11 May 1997, Mr M P Searle wrote: > > > > > > On Sun, 11 May 1997, Mr M P Searle wrote: > > > > > > > > > Would it break anything if the X server was kept running while shutting down? > > > > > (Nothing else, just that one process. The root window is set before starting > > > > > 'halt' - and maybe set again after the 5 seconds.) > > > > > > > > > > Michael, who has too much free time... > > > > > > > > I think that would mean that /usr couldn't be dismounted, which would mean > > > > that you wouldn't get a clean shutdown onthe /usr filesystem, and it > > > > would end up being fsck'ed on startup. I have a big disk, and wouldn't > > > > want to have to wait on that all the time. > > > > > > No - what if the server was on it's own file system? (which wasn't ever fsck'd as > > > it has nothing but the server on it.) My guess is that I'd get a slow shutdown > > > as not all buffers could be written to disk, but the reboot would be OK. Does > > > that sound right? > > > > Sorry for the slow answer, I just finished my OS project, and 6th cup of > > coffee (huh? whazzat?!) ... IF the X server didn't have any files in an > > unfinished state (which I couldn't guarantee, never having tried it) and > > you hacked the /etc/fstab so that it didn't do the fsck, then I think you > > would be right. It'd be slow whenever you actually did the fsck, but not > > normally. > > > > On any other system, I'd think it was a real bad idea, but, hmmm, my > > experience with FreeBSD's filesystems is so good, well, maybe you could > > do it. I wouldn't, but I keep FreeBSD up for weeks ata time (except > > when my OS class forces me into DOS) so I wouldn't realize the time > > savings that someone who turns it on and off every day would see. > > > Well, if it's on its own filesystem and doesn't touch anything else, no problem whatever. If it does touch something else, I'd have to move it to the separate filesystem (assuming it's just a few things.) Time savings?! It takes <1 second to kill everything, plus the 5 second wait and maybe a second to flush buffers. This is just for a splash screen type thing. > There's one other (potential) problem with this: /tmp. X keeps files open > on /tmp, and if tmp is MFS and can't be umounted strange things sometimes > happen. I remember reading on this list (or was it -questions) that 2.1.5 > will not (sometimes) flush its buffers with a MFS /tmp mounted. I've never > seen it on newer systems, but it wasn't consistent on 2.1.5R either, so > you can never know. > Well, my /tmp is MFS, and right now I'm still on 2.1.0 (soon to be 3.0). Can X be told to put its temp files somewhere else (like /var/tmp)? Actually, I've seen it fail to flush all buffers before. I assumed it was some ancient bug that would be fixed when I upgraded.