Subject: Re: NeXT file systems
To: Marc Boschma <marcb@bms.itg.telecom.com.au>
From: Michael Graff <explorer@flame.org>
List: current-users
Date: 02/09/1996 13:54:09
>Maybe the best way to acheieve this is that a separate file system, based
>(or utilising the source of FFS with #defines) could be the best way.
>
>ie. beffs	Big Endian FFS
>    lefss	Little Endian FFS

Yick.  Other than having two seperate in kernel systems, I would write
it more like this:

	When the system is mounted, read in the magic number.  If it's
		the wrong byte ordering, set a ``byte_swap'' flag.
	When reading any on-disk structures which are in machine byte
		order, swap the order if byte_swap is set.

This could be #ifdef'd out with an ``options UNIVERSIALFFS'' or
something.  ;)

Also, fsck and newfs would do the same sort of swapping if asked
nicely to.  I could likely do the newfs and kernel portions, given
enough free time.  The fsck part kinda scares me  ;)

It would make things much easier to use vnd's for testing and such.
I only have access to i386 and pmax -- both seem to have the same byte
ordering.  Can someone make a small (2-4 meg max) file system with
big-endian ordering and ftp it to ftp://ftp.flame.org/incoming?
And remember, an empty file system should compress quite well.  :)

>Now is it enough to just convert the structures, or are there size problems
>with the structures on different architecures (different pack rules for
>alignment etc.) ?

Disk is disk is disk, isn't it?  If the only broblem is byte order, I
would think the on-disk strudtures are well defined and would not
change in size or alignment.

Even 64-bit machines can deal with 32 bits.  :)

Class time.  Being a graduating senior is so nice.  First class @ 2pm,
ends at 3.  Gotta love life  ;)

--Michael

--
Michael Graff <explorer@flame.org>        NetBSD is the way to go!
PGP key on a key-server near you!         Netshade the world!