Hi,
I've updated the file
ftp://ftp.netsd.org/pub/incoming/bouyer/ffs_endian.diff.gz
to the latest state of my developements. This is what I'd like to commit,
unless I get objections.
The utilities: badsect, clri, dump, fsck_ffs, fsdb, fsirand, newfs, dumpfs
and quotacheck have been modified to work on both native and swapped endian
filesystems. The man pages for fsck_ffs and newfs have been updated to
document a new option: -B, which takes either `be' or `le' as arguments.
For newfs, this allow the creation of non-native byte order filesystems.
For fsck_ffs, this ask the conversion from a byte order to another if
needed (this remplace the '-s' options I had introduced in the first
diff set). 
Dump can dump a filesystem in any byte order, the dump is in filesystem byte
order (dumping in host byte order would require big changes to dump, because
directories are dumped as regular files). Restore already knows how to read a
dump in non-native byte order.
The support for non-native endian FFS in the kernel is now conditionned to
"options FFS_EI" (FFS Endian-Independant). Without this the ffs code should be
close to what it was before.

I've run some benchmacks on my test machines, here are the results.
i386: cyrix p166+ (133Mhz) 16Mb, NCR53810 scsi, quantum fireball 2Go
sparc: IPC ("MB86900/1A or L64801 @ 25 MHz, WTL3170/2 FPU"), 20Mb,
	quantum fireball 1.2Go
n: native, s: swapped
EI: kernel compiled with 'options FFS_EI'
All filesystem mounted async.
file read/write measured with 'dd bs=16k'
Directory entries (and inodes) created with a small C program which does
   a 'fopen; fclose' of a filename within a loop (filename derived from the
   loop index). 5000 entries are created on i386, and 1000 on sparc.
Directory read with a 'ls -l' (reads the directory and each inodes)
Directory remove with 'rm -rf'.
system time reported by '/usr/bin/time' for each command.

                file Mb/s (sys time) |    directory entries/sec (sys time)
                write  |   read      |    create  |    read    |   remove
i386     n  2.10 (0.63)| 2.81 (0.38) | 233 (20.02)| 1700 (0.83)| 2272 (1.20)
i386  EI n  1.95 (0.63)| 2.50 (0.36) | 218 (22.15)| 1437 (0.85)| 2119 (1.32)
sparc    n  1.67 (7.74)| 1.66 (5.05) | 122 (7.46) |  332 (1.32)|  549 (1.27)
sparc EI n  1.73 (7.70)| 1.54 (4.98) | 106 (8.84) |  325 (1.27)|  552 (1.27)
sparc EI s  1.81 (7.66)| 1.62 (5.02) |  90 (10.3) |  342 (1.42)|  534 (1.37)

First conclusion: the results are not catastrophic :) The read/write
performances measure may not be trusted here: I don't understand why the
swapped filesystem on the sparc gives better performances than native one.
The physical layout of the file on the drive may have something to do here.
However, on both i386 and sparc, the CPU consumed by the kernel for
'tests and swap' in the ufs_rw{16,32,64} __inlines when reading/writing the
file is not measurable.
The EI code has an impact on inodes/dir entries creation, however. The
performance impact is between 10 and 20% depending on the CPU for native
filesystems. The performance inpact is more important for a swapped FS.
The directory/inode read is not measurable for native filesystems, and seems
to be about 10% for swapped ones.

Of course these are only benchmarks. The performance impact may differ in 
a real use.

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