e07@nikhefh.hep.nl (Eric Wassenaar) (10/25/88)
In non-Apollo NFS implementations it is possible to mount remote NFS filesystems on top of each order, like /etc/mount rhost:/ /mountpoint /etc/mount rhost:/usr /mountpoint/usr so that the whole remote filesystem tree can be transparently accessed using the same pathname syntax, starting at /mountpoint, as on the remote host itself. The mount points must be existing directories. In the current (SR9.7) Apollo NFS implementation, this is impossible. Mount points must be non-existing. They are created as objects of type 'nfs_gate' by the mount operation, and obviously cannot reside on already mounted remote filesystems. It is very unfortunate that Apollo NFS breaks this transparency. Do we have a fundamental limitation, which will persist in future (SR10) releases? Can other people live with this limitation? -- Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 5920412 Home phone: +31 20 909449 Telex: 10262 (hef nl) Internet: e07@nikhefh.hep.nl Bitnet: nikhefh!e07@mcvax.bitnet
e07@nikhefh.hep.NL (Eric Wassenaar) (10/31/88)
The following article in comp.sys.apollo has been rejected during relay from apollo-request to apollo@umix.cc.umich.edu *** Original message follows *** In non-Apollo NFS implementations it is possible to mount remote NFS filesystems on top of each order, like /etc/mount rhost:/ /mountpoint /etc/mount rhost:/usr /mountpoint/usr so that the whole remote filesystem tree can be transparently accessed using the same pathname syntax, starting at /mountpoint, as on the remote host itself. The mount points must be existing directories. In the current (SR9.7) Apollo NFS implementation, this is impossible. Mount points must be non-existing. They are created as objects of type 'nfs_gate' by the mount operation, and obviously cannot reside on already mounted remote filesystems. It is very unfortunate that Apollo NFS breaks this transparency. Do we have a fundamental limitation, which will persist in future (SR10) releases? Can other people live with this limitation? Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 5920412 Home phone: +31 20 909449 Telex: 10262 (hef nl) Internet: e07@nikhefh.hep.nl Bitnet: nikhefh!e07@mcvax.bitnet