[comp.bugs.sys5] File System Type

rjnoe@uniq.UUCP (Roger J. Noe) (05/29/88)

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.  The following
program illustrates my point:

#include <stdio.h>
#include <sys/types.h>
#include <sys/fstyp.h>
#include <sys/statfs.h>

extern void perror();

main(argc, argv)
int	argc;
char	*argv[];
{
	char fs_name[FSTYPSZ+1];
	struct statfs fs;

	for (++argv, --argc; argc > 0; ++argv, --argc) {
		if (statfs(*argv, &fs, sizeof fs, 0) < 0) {
			perror("statfs");
			continue;
		}
		if (sysfs(GETFSTYP, fs.f_fstyp, fs_name) < 0) {
			perror("sysfs");
			continue;
		}
		printf("%s: fstype=%d (%s)\n", *argv, fs.f_fstyp, fs_name);
	}
	return 0;
}

No matter what real, mounted files I give this program as arguments, the answer
is always the same, i.e. S51K.  There appears to be no way to get statfs(2) to
return a f_fstyp corresponding to dufstyp (in the kernel) so that it maps
(through the kernel fsinfo[] table) to DUFST.  I realize that on the remote
system (the server of the mounted resource), the file system IS local, and the
type is S51K, but shouldn't my machine change the f_fstyp to dufstyp before
the system call returns, if it is in fact a remote file system?

Is there no PORTABLE way for a program to tell if a file (system) is remote
or not?
--
	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.

timr@labtam.OZ (Tim Roper) (05/31/88)

In article <479@uniq.UUCP>, rjnoe@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.  The following
> program illustrates my point:
> ...

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.

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 understand that this is so that programs like cp(1)
that decide whether two files are the same by comparing st_dev and
st_ino still work (unless you "remotely" mount a local filesystem).

-Tim.
D

guy@gorodish.Sun.COM (Guy Harris) (06/02/88)

> 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.

Note that, as far as I know, none of this is documented anywhere; therefore, it
should be considered a quirk of the implementation, *not* a documented part of
the interface.  It happens to work under S5R3, but it may break someday.

Note also that "remote vs. local" is only one potentially-interesting file
system attribute; "/proc" is, arguably, a local file system, but you would
rarely want "find /" to go traipsing down it.

rjnoe@uniq.UUCP (Roger J. Noe) (06/03/88)

In article <681@labtam.OZ>, timr@labtam.OZ (Tim Roper) writes:
> In article <479@uniq.UUCP>, rjnoe@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.

les@chinet.UUCP (Leslie Mikesell) (06/04/88)

In article <480@uniq.UUCP> rjnoe@uniq.UUCP (Roger J. Noe) writes:
>....  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.

Doesn't release 3.1's "find" have a -local parameter to keep it from
walking into remote filesystems (useful when the other machine is
doing its own backups and disk accounting..)?  There must be some
reliable way to tell the remote mounts.

Les Mikesell

guy@gorodish.Sun.COM (Guy Harris) (06/07/88)

> Doesn't release 3.1's "find" have a -local parameter to keep it from
> walking into remote filesystems (useful when the other machine is
> doing its own backups and disk accounting..)?  There must be some
> reliable way to tell the remote mounts.

No, not necessarily.  There just happens to be a way that happens to work under
S5R3.x, namely "if the 'dev_t' on which the file exists has its high bit set,
the file system is remote."  This trick also happens to work under SunOS, and
maybe under other versions of UNIX, but it has never, as far as I know, been
specified as an official part of the UNIX system interface.

timr@labtam.OZ (Tim Roper) (06/07/88)

In article <55038@sun.uucp>, guy@gorodish.Sun.COM (Guy Harris) writes:
> > 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.
> 
> Note that, as far as I know, none of this is documented anywhere; therefore, it
> should be considered a quirk of the implementation, *not* a documented part of
> the interface.  It happens to work under S5R3, but it may break someday.

It is described in

	%T RFS Architectural Overview
	%A Andrew P. Rifkin et al
	%J USENIX Conference Proceedings
	%C Atlanta, Georgia
	%D June 1986

But, stat(2) in System V.3 Programmer's Reference Manual and stat(ba_os) in
SVID Issue 2 Volume 1 say that st_dev has no significance other than as
input to ustat(2) and ustat(ba_os) respectively.
D

timr@labtam.OZ (Tim Roper) (06/07/88)

In article <480@uniq.UUCP>, rjnoe@uniq.UUCP (Roger J. Noe) writes:
> ...
> 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.)
A diskless workstation with the root filesystem accessed via RFS springs to
mind :-)  Not that 3.0/RFS could do this as is ...
D

dpg@abstl.UUCP (David Grossman) (06/10/88)

RFS under Sys V Release 3 on the 3b2's is not fully implemented with file
system switch (fss).  There are also some RFS specific system calls.
Apparently, fss and RFS were developed independently and only partially
merged.

Fss was originally developed under Research Version 8 for /proc, a special
type of file system where each active process appears as a file whose name
is the process id and contents contiain kernel user structure info.

The idea to put fss in SVR3 was motivated by the need to merge SV, BSD, and
MS-DOS.  In fact AT&T's 386 version of SVR3 does allow mounting of MS-DOS
diskettes.  Fss works by having a switch table listing functions for each
fs type to perform various actions.

The reason there is so little documentation on fss is that it needs some
major modifications to be completely generic.  Perhaps someone from AT&T
can tell us if what the plans for RFS and fss are in Release 4?

David Grossman			..!wucs2!abstl!dpg
Anheuser-Busch Companies	314/577-3125
One Busch Place, Bldg. 202-7
St. Louis, MO  63118