*BSD News Article 3708


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....)