Return to BSD News archive
Newsgroups: comp.unix.bsd Path: sserve!manuel.anu.edu.au!munnari.oz.au!hp9000.csc.cuhk.hk!saimiri.primate.wisc.edu!zaphod.mps.ohio-state.edu!darwin.sura.net!ra!tantalus.nrl.navy.mil!eric From: eric@tantalus.nrl.navy.mil (Eric Youngdale) Subject: Re: CDROM for 386bsd (Re: ftp software inc, their address is...) Message-ID: <Bxo690.48I@ra.nrl.navy.mil> Sender: usenet@ra.nrl.navy.mil Organization: Naval Research Laboratory References: <AWB.92Nov12101926@otter.uk.ac.ed.aisb> <1992Nov13.073252.9757@ntuix.ntu.ac.sg> Date: Fri, 13 Nov 1992 19:31:47 GMT Lines: 26 In article <1992Nov13.073252.9757@ntuix.ntu.ac.sg> eoahmad@ntuix.ntu.ac.sg (Othman Ahmad) writes: >The most important is to optimise the utilisation of the CDROM. Being a >read only memory system, the McIntosh FS is better in being an extent based, >but it is too far away form 386bsd. > Maybe a slightly modified bsd FFS, can be used, with a few options: > >i) large block sizes, e.g. 32kbyte so that we can put 320k without any >indirect inode pointers. Larger than this will cause too much fragmentation, >because a fragment size of 1k will not be able to fill in the gaps. > This method is attractive because there is no modification to 386bsd >FFS, > >ii) Change it slightly to use extent based FS. I've no idea how difficult it >will be. I can think of *no* good reason to avoid using ISO9660. There are no performance drawbacks, and if you use the Rock Ridge extensions you can even have normal unix filenames, modes, uid/gid, block and character devices and deep directories, all within the ISO9660 standard. The linux filesystem already supports the Rock Ridge extensions (I don't know about 386bsd). All of the files on ISO9660 are already contiguous so you do not have to worry about indirect inode pointers and other such things. -Eric -- Eric Youngdale