From owner-freebsd-hackers Sun Feb 2 16:31:19 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA24583 for hackers-outgoing; Sun, 2 Feb 1997 16:31:19 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA24569 for ; Sun, 2 Feb 1997 16:31:16 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA09896; Sun, 2 Feb 1997 17:29:32 -0700 From: Terry Lambert Message-Id: <199702030029.RAA09896@phaeton.artisoft.com> Subject: Re: Mounting CD-ROM when data not on first track To: joerg_wunsch@uriah.heep.sax.de Date: Sun, 2 Feb 1997 17:29:32 -0700 (MST) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: from "J Wunsch" at Feb 2, 97 09:44:54 pm X-Mailer: ELM [version 2.4 PL24] 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 > > > > But it's not a data area... or rather, it's not a 'data' area. > > > > > > Doesn't matter. > > > It matters, in that this disc is not mountable by FreeBSD. > > But that's not due to the fact that FreeBSD doesn't start to remap the > block/frame numbers, but due to the fact that FreeBSD's cd9660 > filesystem stuff doesn't care for the TOC at all. > > Don't try to `fix' something by uglifying it. You mean, like putting in partition recognition code in the kernel instead of putting it in the FS instead (like you are suggesting here)? I have to disagree with you. They are all members of the same class of logical device creation... > > > Why do you call this `stupid'? That's the same way every Unix does. > > > It's only that they probably miss the mount philosophy, so they could > > > have locked the medium until it will no longer be required for paging. > > > > Uh, "sticky bit"... I can solve the problem in UNIX. > > Sticky bit? Terry, you're riding your time-machine again, you're > currently some ten years back. If you will recall, I've requested the ability to force images totally into local cache on a per FS basis by attributing the FS as "nonlocal". The default behaviour would not do this, but in the case of a large number of diskless machines waiting for a server reboot, it would be a generally "Good Thing". In the case of the sticky bit on an single executable, if the ability to force into local cache existed, then the force should be done. The force should be done in any case for FS objects being used as backing store which have been removed, so that the reference does not go out of scope... otherwise, it will be impossible to implement "savestate" type "shutdowns". So you recall the discussion on how to make an install occur in about 30 seconds by restoring a running installation session and making a tiny number of tweaks? In any case, it is a generally useful enabling technology. Having the machine not barf when running from CD is just an extra bonus. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.