🚀 go-pugleaf

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

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

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.

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

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

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

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

# The only portable way I can think of to see if a file is remote or not
# is to check the mount table in /etc/mnttab.  Although not the official
# kernel version of the mount table, it does contain a flag indicating that
# a file system is remote.  But that would be useful only if you have a
# full path name and can then traverse down the tree and remember the last
# time you passed a mount point and changed file systems (according to the
# mnttab).  Or you could implement in user code your own version of the
# kernel namei() function.  Excuse me, I'm not feeling well.
# 	Roger Noe			ihnp4!att!uniq!rjnoe

You can tell that you have crossed a mount point by noting that
st_dev has changed, - no need for the full path - then compare
your st_dev with st_rdevs for the files in /etc/mnttab to tell
whether you got a remote.
Not very neat, but does beat the hell out of homespun namei.
		Mike Cherepov

In article <482@uniq.UUCP> rjnoe@uniq.UUCP (Roger J. Noe) writes:
>> 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
>
>It is there in the code for find(1) but not on the manual page.  It's entirely

Both -find and -mount are documented in the current 3B2 manual and in the
386 SVr3.1 manual.  I've generally avoided them after being surprised with
the results of some early attempts (not unusual for my attempts to use
find, and I've forgotten the circumstances).  Perhaps I was trying to
avoid crossing a mount point on a remote filesystem..

  Les Mikesell