Re: "tfs" and other filesystems with very short names

[woods%most.weird.com@localhost (Greg A. Woods)]

[ On , September 22, 1998 at 17:36:37 (-0400), 
rvb%sicily.odyssey.cs.cmu.edu@localhost wrote: ]
> Subject: Re: "tfs" and other filesystems with very short names
>
> Very good question.  But there are two.  We call it Coda here so
> the directory is coda.  Then I looked at all the fs's and some used
> fs in the name of their methods and some did not; it was pretty evenly
> split.

I should have been specific -- I meant in the kernel's namespace
(including both symbol space and source filesystem naming)

Let's see (this from directories only in the kernel):

        With "fs" suffix:       Without "fs" suffix:
        =================       ====================

        adosfs                  coda
        filecorefs
        isofs
        miscfs/
                deadfs                  fdesc
                fifofs                  portal
                (genfs)                 union
                kernfs
                nullfs
                procfs
                specfs
                umapfs
        msdosfs
        nfs
        ufs/
                ex2fs
                ffs
                lfs
                mfs
                (ufs)

That's about 16 to 4 if you count real filesystem types.  I've not (yet)
collected any stats to compare how consistent the symbol-naming is
inside the code (but if it's as bad as the device driver universe, then
it's pretty bad).

Of course if you look at the various sbin/mount_* directories in the
user-land source:

        With "fs" suffix:       Without "fs" suffix:
        =================       ====================

        mount_ex2fs                     mount_ados
        mount_ffs                       mount_cd9660
        mount_kernfs                    mount_fdesc
        mount_lfs                       mount_filecore
        mount_nfs                       mount_msdos
        mount_procfs                    mount_null
                                        mount_portal
                                        mount_umap
                                        mount_union

you get a slightly different perspective.

It's a bit harder to change user-land, and indeed there's less need to
change user-land because it's much more obvious that you're dealing with
a filesystem when you use the "fsck", "newfs", "mount", etc. commands.
(I say only a "bit harder" because users rarely use the
<operation>_<type> commands directly.

If I were in my own universe and cared not for history I'd rename all
the directories and symbol names in the kernel to have the "fs" suffix
(and I'd probably shuffle some of the fs directories around and perhaps
make a sys/fs sub-directory to put them all in), and I'd probably also
add the "fs" suffix to the the filesystem type-name suffixes on the
user-land tools (and I'd move all the <operation>_<fstype> commands into
a directory that's not normally in any user's path (i.e.  not even in
root's path), such as /libexec.

But then I'm very draconian about naming conventions and directory
organization....  Unix has always been a bit quirky and inconsistent,
something that comes naturally to a system developed by a community in a
primarily consensus-driven manner.

[Yes the "fs" suffix is redundant when you know you're dealing with
filesystems, but "mount_n" and "mount_f", etc. or "fs/n" and "fs/f" look
pretty funny, at least to me.]

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods%acm.org@localhost>      
<robohack!woods>
Planix, Inc. <woods%planix.com@localhost>; Secrets of the Weird 
<woods%weird.com@localhost>