> Hi Tundra, > > The reasoning behind is that the root directory is a > property of > Solaris, and placing something in her might have some > impact. It could > have been, that the zoneadm halt tried to unmount the > root fs without > success, because the gds is sitting on it.
As a recap - sometimes stop (no matter the source) works correctly, sometimes it doesn't. When it doesn't, it is because zoneadm issues a zfs umount against the root directory and that is still lingering when the underlying zpool's hastorageplus tries to export the zpool. What I have noticed is that when the timing is right (i.e. zfs umount completes first), then the zpool export happens without the 'FORCE' flag set, but when the timing is wrong (and zfs umount has not yet completed), then the 'FORCE' flag is set on the zpool export (and it fails because the device is in use, and then immediately after, the zfs umount completes). I do not understand why the hastorageplus begins it's 'stop' before the zone is completely stopped - what seems to happen is that the zone stops, and then issues zoneadm request to unmount the zonepath; however the gds returns to the rgm with success before zoneadm is actually finished. > > Anyway silly question. you do have adependency > between the sczbt > resource and the HAStoragePlus resource? No question is silly. If I undestand the output of clrs here, then the dependency is set. root at mltstore1:~# clrs show -v smb1_zone | grep smb1 Resource: smb1_zone Group: smb1_rg Resource_dependencies: smb1_lhname smb1_zpool Start_command: /opt/SUNWsczone/sczbt/bin/start_sczbt -R smb1_zone -G smb1_rg -P /smb1_pool0/parameters Stop_command: /opt/SUNWsczone/sczbt/bin/stop_sczbt -R smb1_zone -G smb1_rg -P /smb1_pool0/parameters Probe_command: /opt/SUNWsczone/sczbt/bin/probe_sczbt -R smb1_zone -G smb1_rg -P /smb1_pool0/parameters Network_resources_used: smb1_lhname > > Detlef > > Tundra Slosek wrote: > >> Hi Tundra, > >> > >> One thing which you should never do is move the > >> parameter directory into > >> the root file system for the zone. this is what > might > >> cause the > >> headache, because the sczbt resource accesses the > >> parameter directory > >> and calling zoneadm halt which tries to remove > the > > mount and this might > >> not work. > >> > >> I would suggest to move the parameters directory > to: > >> > >> /smb1_pool0/parameters > >> > > > > I'm not sure I understand why a file open in > /smb1_pool0/smb1_zone/parameters/ would prevent zfs > unmounting of /smb1_pool0/smb1_zone/root, however > it's easy enough to test, I don't see any harm in the > suggested change and I remain open to the possibility > that there is something fundamental I'm > misunderstanding. > > > > Done, (created the directory above, copied the > existing contents of parameters and changed the clrs > Start_command, Stop_command and Probe_command to > point at /smb1_pool0/parameters instead of > /smb1_pool0/smb1_zone/parameters) however the exact > same behavior exists - i.e. overlap between zfs > unmount of /smb1_pool0/smb1_zone/root and > hastorageplus attempting to export the smb1_pool0 > zpool. DTrace log available as per prior efforts, if > anyone thinks it will be helpful, however it doesn't > seem different to me. > > > > -- > > ****************************************************** > *********************** > Detlef Ulherr > Staff Engineer Tel: (++49 6103) > 752-248 > Availability Engineering Fax: (++49 6103) 752-167 > Sun Microsystems GmbH > Amperestr. 6 > mailto:detlef.ulherr at sun.com > http://www.sun.de/ > ****************************************************** > ****** > > Sitz der Gesellschaft: > Sun Microsystems GmbH, Sonnenallee 1, D-85551 > Kirchheim-Heimstetten > Amtsgericht M?nchen: HRB 161028 > Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, > Wolf Frenkel > Vorsitzender des Aufsichtsrates: Martin H?ring > > ****************************************************** > *********************** > > > _______________________________________________ > ha-clusters-discuss mailing list > ha-clusters-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/ha-cluste > rs-discuss -- This message posted from opensolaris.org
