It appears that we are seeing a slow evolution of the FFS filesystem.
I have a few comments to make about this.

The 4.4-Lite NetBSD gave us the 4.4 filesystem.  Using fsck -c3 would upgrade
an old filesystem to the new format, but there was backward compatibility.
No problem.

Next came the clean bit.  I'm not sure how the clean bit is implemented.
Right now, I'm running SunOS and NetBSD on the same machine, using 4.2
filesystems.  It appears that SunOS marks the filesystems as unclean, which
is preferable to having it mark them as clean.  So far - no problem.

We are now discussing putting the entire contents of symlinks in the
directory entry itself (imho a bad idea for many reasons that have already
been expressed here).  Some has suggested keeping the current format, and
putting data for very small files in the inode itself to save a block.

I would also like to see some changes and development work to the filesystems.
A compressing FS would be nice, as would one that uses some form of database
for directories to speed up searches in long directories. (ever seen 25,000
files in /usr/spool/mail?  I have.)

HOWEVER, this should not come at the cost of breaking people who serve
multiple OSes.  Right now I have the choice of booting SunOS or NetBSD on
my Sun3.  Either OS will serve NFS to my Amiga.  I like that.  The day that
the NetBSD FFS format changes (e.g. symlinks) is the day I can no longer
safely boot SunOS.

I hereby request that core do the following: before committing any change
to the fundamental structure of the FS, either ensure that the new code will
work properly with older FSes, or else provide (freeze) the current code,
perhaps as an option OFFS (other/old FFS) so that people like me can

mount -t offs /dev/sd0g /sunos/usr

and the like.

-- 
David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto
           email: dej@eecg.toronto.edu, finger for PGP public key
         For a good time, telnet torfree.net and log in as `guest'.
          Click me!