Kind of a divergence from original post, but a summary of one of its subjects
regarding NFS mounts within one system:
I'd like to thank FrankB for a fruitful off-list discussion leading me to these
bugs below regarding NFS server being its own NFS client, global- or
local-zoned, due to contentions with UFS.
The bug 5065254 connects all bugs related to this problem and describes some
interesting "gory details", as Frank put it :)
According to bug 6811806 in particular, the "automount service correctly
detects such local mount requests" within the global zone, but can fall prey
when automounting a global zone's NFS shares from a local zone:
Nonetheless, I stand by my statement that I haven't seen these problems in my
practice (completely or almost - if those 2-3 accounted problems I had were
anyhow related to this).
However, as we speculated, this may be due to the fact that the overwhelming
majority of my systems (except 1 or 2 servers) used the "unsupported" scheme
with zone roots being their own ZFS datasets, and certainly the distrib/dump
datasets shared over NFS were on the ZFS pool.
So this could be a no-problem for me on older (Sol 8-9) systems with UFS due to
automounter smartness, and a no-problem on Sol10/SXCE due to no UFS-based
shares in my case.
I do also state from my previous tests that global-to-local zone loopback
mounts are (were a year ago) more efficient than NFS, especially when we had a
compiler-like I/O pattern creating and modifying thousands of small files, but
it is less flexible to set up or modify on-the-fly. Well, there are always
For generic systems I prefer NFS and automounter, and can always tune with lofs
Kudos to FrankB,
This message posted from opensolaris.org
zones-discuss mailing list