Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!software.org!kint From: kint@software.org (Rick Kint) Newsgroups: comp.sys.apollo Subject: Re: Domain Ring and NFS Message-ID: <1661@sunny.software.org> Date: 13 Dec 89 15:40:52 GMT References: <8912131306.AA14840@unix.sri.com> Sender: usenet@software.org Reply-To: kint@software.org (Rick Kint) Organization: Software Productivity Consortium, Herndon, Virginia Lines: 36 In article <8912131306.AA14840@unix.sri.com> ramu@tcipro.UUCP (Ramu Iyer) writes: >We have a network of Apollos and Suns at our site. The Apollos talk to each other through the Domain >Ring network. The Apollos and Suns cannot talk to each other since NFS isn't running on *both* the >Apollos and Suns. > >Could anyone outline the advantages of having NFS on an Apollo network apart from the Domain Ring Network? > >Thanks in advance. > >--ramu iyer Well, the obvious (and compelling) advantage is that Suns and Apollos will be able to share files if you run NFS on your ring... There's good news and bad news about Apollo NFS. The good news is that it lets you mount the entire ring through a single server: /etc/mount -t nfs foo:// /nfs/apollo will mount an entire Domain internet (as seen by //foo) on /nfs/apollo on a Sun. You then use node names below that. This helps keep /etc/fstab and/or your automount map within bounds, although it may not work well with estabished naming conventions. The bad news is that since mount points are typed files (nfs_gate), you can't mount remote filesystems on remote directories (like you can on Suns and other native UNIX boxes), so you lose the filesystem hierarchy on remote mounts. All of our mount points for a given host are in a flat namespace. It looks like they've fixed a lot of bugs at NFS 2.1, so I'm not sure what the other bad news is at present. It's worth trying. -- Rick Kint CSNET: kint@software.org Software Productivity Consortium ARPANET: kint%software.org@relay.cs.net Herndon, VA UUNET: ...!uunet!sunny!kint