Hi,
I've made big progress in getting ffs read both big and little endian
file systems. A preliminary (but working :) version is available
at ftp.netbsd.org:/pub/incoming/bouyer/ffs_endian.diff.gz.

Features are:
kernel can mount read/write both big and little endian ffs. The selection
is made on the superblock magic order at mount time.

fsck_ffs can work on both endian, and will convert from one to another
if the '-s' flag is given. However, the filesystem will be unrecoverable if
fsck is stopped before the end of the convertion for some reason.
I really don't know how to be safer here. Once fsck starts rewrinting the
fielsystem metadatas, there is no way to know where it stopped.

Other filsystem utilities (badsect, clri, dump, fsdb, fsirand, newfs, tunefs,
dumpfs, quotacheck - let me know if I missed some !) will work on both
byte order. newfs will be able create both byte order ffs (not done yet,
but will be soon).
Quotacheck will be able to work on any byte order, but the quota file will
always be used in host byte order - if you move a disk with user quotas,
you will have to rerun quotacheck on it. If peoples feels it's a too strong
limitation, I can have a look at this too. My understanding of things are
that such situations should be exceptional. I can't see the use of quotas
on removable medias.

On the kernel side, I added a 'int um_flags' to struct ufsmount.
For now it can only take one value - UFS_NEEDSWAP. This flags is checked
at various place in the kernel when reading/writing metadatas.
As inodes and the superblocks have a in-memory copy, they are converted
in whole at read/write time (exept the blocks addresses in the inode).
The blocks adresses (in inode or indirect blocks), cylinder groups and the
directory infos are converted at use time, as the in-memory copy is
the disk buffer itself. Things could maybe be improved here by adding a
cylinder group cache, as does linux, but this needs further studies.

I plan to commit this next friday, unless I get negative comments sine then.

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
--