File System Type (statfs, sysfs)

[Roger J. Noe]

In article <681 at labtam.OZ>, timr at labtam.OZ (Tim Roper) writes:
> In article <479 at uniq.UUCP>, rjnoe at uniq.UUCP (Roger J. Noe) writes:
> > The following pertains to UNIX System V Release 3.1.1 Version 3 for the AT&T
> > 3B2 computer.  Perhaps I have misunderstood the purpose of the statfs(2)
> > system call, but when I use it on remote file systems (RFS), I always get
> > the same file system type as local (non-RFS) file systems.
> 
> When you statfs(2) a remote (RFS) file, f_fstyp gives the filesystem
> index from the remote machine.  Beware that eg. if "S51K" on the remote
> machine is a different index to what it is on the local machine you
> get the *former*.  This can and does happen if the local and remote
> machines have different filesystems configured.  Therefore using
> sysfs(GETFSTYP, ...) to map an f_fstyp obtained from statfs(2) onto a
> name is not correct in general, as sysfs(2) uses the local mapping.

The question was not so much what does happen as what should happen.
Should statfs give you an index into the remote machine's fsinfo[] and
fstypsw[] tables when you have no access to those tables?  Such a number
is meaningless, unless you're planning on passing it back to the remote
machine at some time.  But since you do have (limited) access to your own
machine's tables via sysfs(2), should not the f_fstyp in the statfs
structure be changed to your local dufstyp when the DUSTATFS or DUFSTATFS
remote system call returns?  This would be what I could call meaningful
and reasonable behavior.  If this is not done, the f_fstyp returned is
absolutely useless.

> If you stat(2) a remote file you get the high order bit of st_dev
> turned on so you can tell that it is remote if you want to.  Also the
> major number tells which machine it resides on.  And the minor
> number tells which filesystem on the remote machine the file
> resides on.  The major and minor are uninteresting on their own but can
> be used to see whether two files reside on the same machine and/or
> filesystem. . . .

I know that this works and you know that this works, but it's not really
documented anywhere (unless you call kernel code documentation).  I remember
noting from that code that the upper byte of st_dev was set to the one's
complement of the gdp index and the lower byte to the mount table index
(or something like that) but I'm not counting on this all staying that way
for future versions of System V.  However, if we're going to be provided
with "file system types" they should be used uniformly.  If you have an
inode entry for a remote file, your i_fstyp is set to your dufstyp.  That
datum has local significance.  If you statfs the same file, f_fstyp should
be the same, not the remote machine's s5fstyp.  I think this was merely an
oversight and believe this was how statfs and sysfs were intended to work.
If the f_fstyp is set to your local dufstyp when the remote syscall returns,
this would probably break nothing that currently exists in System V Release
3.  I searched through 3.0 source code and the only time I found any program
or library routine using f_fstyp after doing a statfs was in mount(1M) and
under very specific circumstances:
	1. Neither -d nor -f options specified
	2. Pathname passed to statfs is "/"
	3. Followed by a sysfs(GETFSTYP) to get the fsname for this f_fstyp
The resulting file system type name will never be DUFST.  (The purpose of this
was to get the default fstyp for a local mount when no -f was specified.)

The only other commands that even call statfs are df and fusage, and then
only to get other members of the statfs structure (df is obvious; fusage
needs f_bsize).  My opinion is that the observed behavior is incorrect and
my usage of f_fstyp after a statfs on a remote file is correct, especially
that sysfs(GETFSTYP) should give me DUFST.  But since none of the Release 3
code greatly depends on determining whether a given file is remote or local
(indeed, the objective was to be transparent at the user level), this was
probably never really checked.
--
	Roger Noe			ihnp4!att!uniq!rjnoe
	Fox Valley Software		ihnp4!nwuxf!rjnoe
	Uniq Digital Technologies	+1 312 510 2105
	Batavia, Illinois  60510	41:50:56 N.  88:18:35 W.