Xref: utzoo comp.bugs.sys5:460 comp.unix.wizards:9164 Path: utzoo!dciem!nrcaer!scs!spl1!laidbak!att!uniq!rjnoe From: rjnoe@uniq.UUCP (Roger J. Noe) Newsgroups: comp.bugs.sys5,comp.unix.wizards Subject: Re: File System Type (statfs, sysfs) Message-ID: <480@uniq.UUCP> Date: 3 Jun 88 14:26:11 GMT Article-I.D.: uniq.480 References: <479@uniq.UUCP> <681@labtam.OZ> Sender: news@uniq.UUCP Organization: Uniq Digital Technologies, Batavia, IL Lines: 69 Summary: st_dev < 0 not a great solution 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.