*BSD News Article 16890


Return to BSD News archive

Xref: sserve comp.unix.aix:23030 comp.unix.aux:9588 comp.unix.bsd:12077 comp.unix.cray:802 comp.unix.sys5.r4:3008
Newsgroups: comp.unix.aix,comp.unix.aux,comp.unix.bsd,comp.unix.cray,comp.unix.sys5.r4,cmp.unix.xenix
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!dog.ee.lbl.gov!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: Support for 4.2BSD Fast File System
Message-ID: <1993Jun7.232802.8354@fcom.cc.utah.edu>
Keywords: bsd filesystem
Sender: news@fcom.cc.utah.edu
Organization: Weber State University  (Ogden, UT)
References: <C815MC.10I@queernet.org> <1ukgtd$gmr@mail.fwi.uva.nl> <C823vt.7up@queernet.org>
Distribution: inet
Date: Mon, 7 Jun 93 23:28:02 GMT
Lines: 36

In article <C823vt.7up@queernet.org> rogerk@queernet.org (Roger B.A. Klorese) writes:
>This is a special case; Sun decided to keep their on-disk format
>identical.  You cannot, however, move a filesystem image between
>SVR4/Intel and Solaris 2, or SVR4/Intel and SunOS, or even (no byte
>order issues) Mips RISCos and either Sun operating system.  The
>exact on-disk layouts differ somewhat.

It's a byte order, device driver, and volume header issue.

The disklabel must be recognized by the kernel on the machine for the
disk partitions to parse properly.  Once this is correctly accomplished,
/dev entries will refer to specific partitions on the disk.  In order to
actually mount the disk, the mount op in the vfsops struct for the file
system has to be hacked to recognize what information is in the volume
label/volinfo struct.  Sun has added "clean bit" fields to the disk to
speed fsck's, among other things, so this requires a change to the decode.
After that, it's pure FFS as far as the layout goes.

The majority of differences in SunOS are code structure; the differences
in Solaris are SMP changes, and Sun won't document those to anybody without
a source license (and I mean *anybody*).

The byte-order issues will chew you up on the disklabel, volume info, and
the on disk inodes and superblocks -- basically, anywhere data objects or
structures are written to disk.  There are also alignment issues which
have to be taken care of to correctly decode the structures, since the
padding will vary from machine to machine.  *BUT* it *is* possible to mount
FFS disks across architectures if you are willing to eat the conversion
overhead.


					Terry Lambert
					terry@icarus.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.