pezely@cis.udel.edu (Daniel Pezely) (10/09/90)
Wouldn't it be convienent if machines running Minix, which had a file system on a SCSI drive, could read Berkeley (or even SunOS) file systems? First of all, would that be legal? (Assuming the site had a BSD, SunOS, AT&T, etc license, of course.) But more importantly, how difficult would that be to pull off? It would be nice to be able to just take an external drive off of a SparcStation and slap it on, say, a 386, then use it and put it back. OK, for those worried about legalities, how about doing it to read dos hard disks? What would the scale of such a task be? -Cowboy Dan -- R+D Cowboys: HITL, Seattle CSL, U Delaware Pezely@hitl.VRnet.washington.edu Pezely@udel.edu
henry@zoo.toronto.edu (Henry Spencer) (10/10/90)
In article <32883@nigel.ee.udel.edu> pezely@cis.udel.edu (Daniel Pezely) writes: >Wouldn't it be convienent if machines running Minix, which had a file >system on a SCSI drive, could read Berkeley (or even SunOS) file systems? >First of all, would that be legal? (Assuming the site had a BSD, >SunOS, AT&T, etc license, of course.) Provided that one can know the format without violating nondisclosure -- practical for all the systems I'm aware of, since they generally don't mark the manuals top secret, just the code -- then licensing is not required if you write your own code to read their format. This is just as well, because licenses generally cover *specific CPUs*, not all machines at a site. Even Unix "site licenses" normally include a list of CPU serial numbers, and new ones have to be added to the list before they are legitimate. >But more importantly, how difficult would that be to pull off? Writing your own code to read Berkeley/Sun filesystems (the differences are minor) would not be trivial but would not be prohibitively hard. If you want to be able to write the filesystem as well, that gets rougher, because Berkeley storage allocation is complicated. Porting existing Berkeley/Sun code to Minix, which is what you'd really need the license for, would be hard. -- Imagine life with OS/360 the standard | Henry Spencer at U of Toronto Zoology operating system. Now think about X. | henry@zoo.toronto.edu utzoo!henry
adrie@philica.ica.philips.nl (Adrie Koolen) (10/10/90)
In article <32883@nigel.ee.udel.edu> pezely@cis.udel.edu (Daniel Pezely) writes: >Wouldn't it be convienent if machines running Minix, which had a file >system on a SCSI drive, could read Berkeley (or even SunOS) file systems? > >First of all, would that be legal? (Assuming the site had a BSD, >SunOS, AT&T, etc license, of course.) I see no reason why it could be illegal to read or write to a Unix file system. >But more importantly, how difficult would that be to pull off? I've thought about providing a utility program, like dosdir/read/write, to let the SparcStation Minix manipulate the SunOS file systems on floppy and hard disks. I've not written such a program (yet), because it's not entirely trivial and one can always use tar to transfer files from SunOS to Minix (and the other way around), via floppy diskettes or a dummy hard disk partition. Mounting a SunOS file system under Minix would be quite difficult. In any case, the Minix FS should be changed on many places and you're just changing one specific file system format (Minix) to another (SunOS). For another Unix like file system, you'll probably have to change again! >It would be nice to be able to just take an external drive off of a >SparcStation and slap it on, say, a 386, then use it and put it back. In this example, you'll probably get problems with the endianess of the Sparc (hi-byte-first) and the 386 (lo-byte-first). Note that it could be done, but you will have to do quite some rewriting on the FS! Adrie Koolen (adrie@ica.philips.nl) Philips Innovation Centre Aachen
bruner@sp15.csrd.uiuc.edu (John Bruner) (10/11/90)
I seem to recall that for testing purposes Berkeley first implemented the 4.2BSD filesystem under 4.1BSD with user-mode code that wrote to files. However, my memory of this is pretty hazy. If indeed this is true, then using that code in application programs might be the easiest path for reading and writing BSD filesystems. -- John Bruner Center for Supercomputing R&D, University of Illinois bruner@csrd.uiuc.edu (217) 244-4476
pezely@cis.udel.edu (Daniel Pezely) (10/11/90)
>I seem to recall that for testing purposes Berkeley first implemented >the 4.2BSD filesystem under 4.1BSD with user-mode code that wrote to >files. However, my memory of this is pretty hazy. If indeed this is >true, then using that code in application programs might be the >easiest path for reading and writing BSD filesystems. This is what I was thinking of. After all, isn't minix's file system code a system program and not in the kernel? So, how about if there were two file system daemons running? One for normal minix file systems and the second for SunOS. I'll play with having two fs daemons first, and that might increase performance of the system anyway. After all, on a SunOS file server, it is recommended that you run 6 or 7 nsfd programs so that the overall average time of NFS requests handled is improved. Message passing doesn't have to be handled all by one program, but I don't want to get into a discussion about that (yet). I do realize that problems will be encountered and a decrease in performance will arise due to byte ordering and such, but the flexibility of being able to take a drive with you from site to site greatly outweighs all that. -cowboy dan -- R+D Cowboys: HITL, Seattle CSL, U Delaware Pezely@hitl.VRnet.washington.edu Pezely@udel.edu
jca@pnet01.cts.com (John C. Archambeau) (10/11/90)
pezely@cis.udel.edu (Daniel Pezely) writes: >Wouldn't it be convienent if machines running Minix, which had a file >system on a SCSI drive, could read Berkeley (or even SunOS) file systems? First of all, BSD and SunOS are the same animals with respect to file system structure. All SunOS is basically is BSD Unix 4.3 with some of Sun's code added. All you basically need is a BSD 4.2 file system module to replace Minix's fs module, but then of course, you're running into a multiple file system problem. What if I have one Minix file system on this Seagate ST251 a BSD 4.2 file system on this CDC Wren IV hooked to my Adaptec AHA 1542B? You'd need a 'smart' file system module to determine the file system type. I suppose this wouldn't be too difficult, but remember the BSD 4.2 file system was designed with some performance issues in mind. The Minix file system was designed to get the point across about general Unix file system structure with the common denominators being the superblock, free list, and inode table. One, the BSD file system has superblock backups at a spaced interval, the Minix file system only has one superblock per file system. So you see, you have some radical FS implementation changes. >First of all, would that be legal? (Assuming the site had a BSD, >SunOS, AT&T, etc license, of course.) I don't see any problems providing you don't use any AT&T, BSD, or Sun code to accomplish the job. Sure, the data structures are the same, but I know that the authors of the DOS utilities for Minix didn't pay a license to MicroSoft to write the DOS file system utilities. >But more importantly, how difficult would that be to pull off? I have a book here on the design of BSD Unix, but I haven't had a chance to read it, but I do know that the file system module would have to be rewritten to handle both the BSD 4.2 file system and the Minix file system. Of course, then there's a similiar argument if you want to do it for Xenix and Unix System V file systems. Where do you draw the line? Where will Minix stop? Or do you want to make a universal file system read utility that will decipher the file system you have on a given disk and allow you to read any given file system from a floppy? See my point? >It would be nice to be able to just take an external drive off of a >SparcStation and slap it on, say, a 386, then use it and put it back. What would be the point in taking a drive off the SPARCstation and putting it back on? It's a novel idea for the Minix wish list, but I have yet to see a Sun customer that I've installed a Sun for 'take a drive off the Sun and put it back later.' Are you sure you don't want a tape driver that can read QIC-24 tapes instead? Personally, the only time I take a drive on and off a machine is to test it, otherwise the drive stays where it belongs. Don't mean to chastise you or anything, but your idea of why Minix should be able to read/write to BSD 4.2 file systems doesn't quite make sense to me in application. For floppy disks and removable media drives I can understand, but hard drives just aren't mean to be taken on and off an system on the fly. See my meaning here? >OK, for those worried about legalities, how about doing it to read dos >hard disks? What would the scale of such a task be? My understanding is that Minix already handles MS-DOS 3.30 file systems just fine. Or has this been worked out fully yet? I know that I had no problems in reading DOS 3.30 primary partitions when I ran Minix 1.3 awhile back on my 286 box. Right now I'm just waiting to see Minix 386 to become a bit more solid before I allocate hard drive space for it and tinker around with it. // JCA /* **--------------------------------------------------------------------------* ** Flames : /dev/null | Small memory model only for ** ARPANET : crash!pnet01!jca@nosc.mil | Unix? Get the (*bleep*) out ** INTERNET: jca@pnet01.cts.com | of here! ** UUCP : {nosc ucsd hplabs!hd-sdd}!crash!pnet01!jca **--------------------------------------------------------------------------* */