rasesh@bucasb.bu.edu (03/05/87)
We are planning to buy System V based Iris 3010 graphics workstation. Our concern is making the files portable between 4.2BSD based Celerity system and our new workstation. Can we remote mount the filesystem from 4.2 BSD based system onto the new System V based workstation usin NFS? Silicon Graphics (makers of Iris) do have their own NFS. Does any one know about NFS use for System V. Our network is Ethernet TCP/IP and currently we are sharing filesystems from remote machines via NFS which are on 4.2BSD. Another concern is about transfer of files through ftp, which I think should not have any problems. -rasesh ( rasesh@bucasb.bu.edu )
guy%gorodish@Sun.COM (Guy Harris) (03/06/87)
> Our concern is making the files portable between 4.2BSD based Celerity system > and our new workstation. Can we remote mount the filesystem from 4.2 BSD > based system onto the new System V based workstation usin NFS? Assuming everybody did things correctly, there should be no problem; other implementations of NFS on top of kernels based primarily on S5 can talk quite happily to implementations of NFS on top of kernels based primarily on 4.2BSD. Assuming the mostly-S5-based kernel either 1) implements SunOS's "getdirentries" or S5R3's "getdents" call, or some such "get a directory entry" call (and the "directory library" - "opendir", "readdir", etc. - is provided) or 2) uses some trick, such as the one alluded to in the "NFS Portability" paper in the Atlanta USENIX proceedings, to make "read"s on directories look (sorta kinda) like reads on a V7-style directory you shouldn't have a problem with directory formats, unless you have files with names longer than 14 characters. If the first approach is taken, then applications written with the directory library (and that don't otherwise assume that file names are no longer than 14 characters) should work fine no matter how long the file names on the Celerity are. If the second approach is taken, you may have trouble with files that have names longer than 14 characters, but files with 14-character or shorter names should cause no problems. You may also get surprises if the Celerity has files with inumbers greater than 65535, since "ino_t" is an unsigned short on systems not using the 4.2BSD file system. In practice, however, you may not have any such files (I'm sure somebody out there has created one, but I doubt they're very common - I just tried "df -i" on a machine here with a lot of files, and the largest "iused" was 32342). Then again, unless your application (or a library routine it calls) looks at the i-numbers returned from directory reads or "stat"s, it won't even notice. Of course, if the S5 box uses the 4.2BSD, rather than the V7, file system, neither of those two will be different. "ustat" may or may not work on NFS file systems (it does on SunOS, but not systems running the the Lachman Associates/The Instruction Set S5R2 NFS). (No, we did not change the arguments to "ustat"; if a process on machine X does a "stat" or "fstat", and uses the "st_dev" field in a call to "ustat", it will get the proper file system statistics for the file system on which the file that was "stat"ted or "fstat"ted resides. We just don't guarantee that you can hand "st_dev" to another machine and have *it* get the same results when doing a "ustat" that you got....) You won't be able to do a "utime(pathname, (struct utimbuf *)NULL)" over the wire to the Celerity, since NFS does not include a "set the modification and access times on the file to the current time if the requestor either 1) owns the file or 2) has write permission on it". Other "utime" calls should work. You will probably also not be able to change the ownership of a file on the Celerity from the S5 machine, unless they've changed their UNIX to permit it. This is as it should be; the "owner" of the file system, i.e. the server, should decide whether to permit this or not, and has the right to forbid it even if the client permits it. Permitting it would cause problems with the disk quota mechanism. You may or may not be able to use named pipes over the wire. Some NFS implementations (including SunOS's) support them, but I don't think they all do so in the same fashion. These are all pretty much "corner cases". Most operations won't know or care what flavor of UNIX is supplying the files. > Another concern is about transfer of files through ftp, which I think > should not have any problems. FTP is FTP; if there's a bug or other misfeature in one or the other of the implementations, you may have a problem, but the flavor of UNIX doesn't enter into it.