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