Return to BSD News archive
Path: sserve!manuel!munnari.oz.au!uunet!auspex-gw!guy From: guy@Auspex.COM (Guy Harris) Newsgroups: comp.unix.bsd Subject: Re: 386BSD filesystem types. Can I mount a SunOS 4.1.2 disk? Message-ID: <14082@auspex-gw.auspex.com> Date: 16 Aug 92 11:34:51 GMT References: <1992Aug6.052627.22670@zip.eecs.umich.edu> <7087@skye.ed.ac.uk> Sender: news@auspex-gw.auspex.com Organization: Auspex Systems, Santa Clara Lines: 34 Nntp-Posting-Host: auspex.auspex.com >>Hi. Is the 386BSD filesystem a 4.2 filesystem? Ie, could I mount >>a Sun formatted, ... disk? (Formatted under 4.1.1 or later of SunOS). As noted by Casper Dik, the "Ie" doesn't belong there. They may both be 4.2 file systems, but unless the Sun disk came from a Sun386i, the byte orders differ (and the 386i didn't get a 4.1.1 port). >Note that Sun have made some changes to the file system format which >may mean that your Sun disk is not a 4.2 filesystem. Well, actually, it ceased being a "4.2" file system in 4.1; it's a 4.3-tahoe file system there.... (It picked up most 4.3-isms in 4.0, although directory truncation didn't show up until 4.1.) However, 386BSD is presumably also a 4.3-tahoe or later file system. >In particular, >they introduced something they call "clustering" in 4.1.1. That didn't involve any file system format changes; it's just changes to the code, so that with "rotdelay" of 0, the UFS code can do sequential reads and writes in "maxcontig"-sized chunks, rather than in file system blocks. 4.1.1 file systems with "rotdelay" of 0 and "maxcontig of 7 (7 8K blocks, or 56KB chunks) should be readable by BSD-file-system code even if it doesn't support clustering - modulo other file system changes, and byte-order issues, and the like. Now, one "other file system change" is that the "fs_headswitch" and "fs_trkseek" fields in the 4.3-tahoe and later superblock are, in SunOS, an 8-byte file system ID. The file system id is "currently unused and unmaintained"; I don't know whether 386BSD uses the "fs_headswitch" or "fs_trkseek" fields, so this may not be a problem. (Then again, without code changes, the byte order is a bigger problem, as noted....)