Summary: there's a workaround - read on.
Rob Brown wrote:
> On 12/12/2008 14:30, "Dean Roehrich" <Dean.Roehrich at sun.com> wrote:
>
> On Fri, Dec 12, 2008 at 09:36:07AM +0000, Rob Brown wrote:
> > Hi,
> >
> > I?ve several Solaris 10 update 4 systems (x86) running QFS that
> can?t mount
> > their QFS volume at boot.
> >
> > If the system boots and I manually mount the filesystem it works fine,
> > however if I leave it in the /etc/vfstab to mount at boot and
> reboot the
> > system, it drops into a maintenance state with the following in
> the logs:
> >
> > [ Dec 11 17:37:22 Executing start method
> ("/lib/svc/method/fs-local") ]
> > mount_samfs: SC_mount() error: Transport endpoint is not connected
> > WARNING: /sbin/mountall -l failed: exit status 6
> > [ Dec 11 17:37:58 Method "start" exited with status 95 ]
[changed post ordering, apologies if this seems pernickety of me]
> VERSION: 4.6.5,REV=5.10.2007.03.12
We're running the same revision here at the ANU Supercomputer Facility, and
hit the same problem.
/lib/svc/method/fs-local calls /sbin/mountall -l, which with the -l option
takes anything that:
- isn't nfs or cachefs fstype
- doesn't have "global" in the mount options
to be a local filesystem, and blithely tries to mount it. In pre-Solaris 10
days the network would have been up by now, courtesy of
/etc/rcS.d/S30network.sh or similar, but my theory here is that there's a
race between the network initialisation SMF service and the invocation of
/lib/svc/method/fs-local, causing the first shared QFS mount done by
/sbin/mountall -l to die with the "transport endpoint is not connected" error.
There's an easy workaround though: just add "global" to the mount options
for the QFS filesystems. /sbin/mountall -l will ignore them, and
/etc/rc2.d/S73samfs.shared will mount them just fine, albeit with a
complaint about the ignored global option.
example vfstab line from one of our QFS clients:
projects - /qfs/projects samfs - yes shared,global
One thing we have seen even with this workaround is that sometimes not all
the mounts go through at boot time. For example, this particular client had
12 shared QFS mount lines in /etc/vfstab, and last time it was booted one of
them failed to mount. A subsequent manual mount of the missing filesystem
worked just fine.
I keep meaning to set up another client to work out what is going wrong - on
the machines where we've seen this happen, we haven't had the luxury of
taking time to do more investigation. This stops us from automatically
exporting QFS filesystems via NFS, even once you workaround the race between
SMF's NFS exporting and the SAM-FS mounts. Hopefully I can say more on this
soon when I've looked into it further.
--
Jason.Ozolins at anu.edu.au ANU Supercomputer Facility
Leonard Huxley Bldg 56, Mills Road
Ph: +61 2 6125 5449 Australian National University
Fax: +61 2 6125 8199 Canberra, ACT, 0200, Australia
