Date: Mon, 3 Feb 1997 09:30:55 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Subject: Re: Mounting CD-ROM when data not on first track Message-ID: <Mutt.19970203093055.j@uriah.heep.sax.de> In-Reply-To: <199702030029.RAA09896@phaeton.artisoft.com>; from Terry Lambert on Feb 2, 1997 17:29:32 -0700 References: <Mutt.19970202214454.j@uriah.heep.sax.de> <199702030029.RAA09896@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
As Terry Lambert wrote: > > 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)? No. These dreaded CD-ROM tracks have one thing different from normal partitions: the filesystem code in it still references the disk by absolute frame (block) numbers. Filesystems that live in partitions do not do this, they describe the filesystem relative to the start of the partition. The CD code needs both. The one-partition-per-track is needed for things like putting up to 99 UFS filesystems on a disk. As i wrote, i've once got a sample implementation for this, but later realized that this is not very useful because it's not what ISO-9660 is using. The one large partition covering everything (and leaving holes for the audio tracks) is what we've already got by now. It is the model that underlies ISO-9660. So the only thing that is needed is to find out about the position of the root directory is to see what's the track to read this from. You can learn this from the CD-ROM TOC. Reading the TOC (CD-ROM metadata) as part of the normal CD-ROM data stream doesn't fit into the model. Mapping the TOC at the beginning of the data stream (and offset all data blocks) would be terrible, and defeats the idea of being able to test an ISO-9660 image e.g. on a vn device, even if it's not multi-session. Mapping the TOC into negative device offsets isn't more elegant either. So in the end, i found that this _is_ a cd9660 matter infact (and not true device partitioning), so it doesn't violate the layering idea too much to have the cd9660 filesystem code doing the investigation of its own -- by calling the CD-ROM ioctl. Sure, you lose for an ISO-9660 ``multi-session'' image on a vn device, but i don't have an idea how to solve this, other than by allowing an explicit block number to be passed to the mount_cd9660 command to tell it where to look for the directory. > > > 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". Sorry, i misread your comment and thought you were referring to something that does already exist. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Mutt.19970203093055.j>