Steve,

Thanks for this information.

I ran through the commands and this is what I see.

> ::kmem_cache ! grep rnode
ffffffffa6438008 rnode_cache               0200 000000      656    70506
ffffffffa643c008 rnode4_cache              0200 000000      968        0

When I run the following:
ffffffffa6438008::walk kmem | ::print rnode_t r_vnode | ::wnode2path

I can see two listed fs's
/zone/zonetest-new/root/opt/xxx/yyyy/logs.tar
/zone/zonetest-new/root/var/xxx/xxxx

But when I run the ::fsinfo command there are no nfs mounted filesystems in
the zonetest-new fs. Both of the fs's listed were nfs mounted when the zone
was up and running.

It really looks like someone was doing something with the logs.tar file at
the time the zone was coming down which probably started all my problems.

I really appreciate all this info.

Thanks,
Derek


On Thu, May 7, 2009 at 12:34 AM, Steve Lawrence <stephen.lawre...@sun.com>wrote:

> Related comments from bug below (X'ed out some paths):
>
> The zone in question clearly has too many references
>
> > 0000030004a09680::print zone_t zone_ref
> zone_ref = 0t11
>
> Ten too many, to be precise.  So what's holding onto the zone?  Well the
> rnode
> cache has 5 entries
>
> > ::kmem_cache ! grep rnode
> 0000030003a1e988 rnode_cache               0000 000000      640   572988
> 0000030003a20988 rnode4_cache              0000 000000      984        0
> > 0000030003a1e988::walk kmem | ::print rnode_t r_vnode | ::vnode2path
> /opt/zones/z1/root/XXXX
> /opt/zones/z1/root/XXXX
> /opt/zones/z1/root/XXXX
> /opt/zones/z1/root/XXXX
> /opt/zones/z1/root/XXXX
>
> even though no nfs filesystems are mounted
>
> > ::fsinfo
>            VFSP FS              MOUNT
> 000000000187f420 ufs             /
> 000000000187f508 devfs           /devices
> 0000030000315780 ctfs            /system/contract
> 00000300003156c0 proc            /proc
> 0000030000315600 mntfs           /etc/mnttab
> 0000030000315480 tmpfs           /etc/svc/volatile
> 00000300003153c0 objfs           /system/object
> 00000300039987c0 namefs          /etc/svc/volatile/repository_door
> 00000300039984c0 fd              /dev/fd
> 0000030003a99e00 ufs             /var
> 0000030003998400 tmpfs           /tmp
> 0000030003a99680 tmpfs           /var/run
> 0000030003a98f00 namefs          /var/run/name_service_door
> 0000030003a98b40 namefs
>  /var/run/sysevent_channels/syseventd_channel...
> 0000030003a989c0 namefs          /etc/sysevent/sysevent_door
> 0000030003a98780 namefs          /etc/sysevent/devfsadm_event_channel/1
> 0000030003a98540 namefs          /dev/.zone_reg_door
> 0000030003a983c0 namefs          /dev/.devfsadm_synch_door
> 0000030003a99380 namefs          /etc/sysevent/piclevent_door
> 00000300044b1d80 namefs          /var/run/picld_door
> 0000030003a99200 ufs             /opt
> 00000300044b0700 namefs          /var/run/zones/z1.zoneadmd_door
>
> And as apparent from the path, all of those rnodes refer to zone z1 through
> their mntinfo structure
>
> > 0000030003a1e988::walk kmem | ::print rnode_t r_vnode->v_vfsp->vfs_data |
> ::print mntinfo_t mi_zone | ::zone
>            ADDR     ID NAME                 PATH
> 0000030004a09680      1 z1                   /opt/zones/z1/root/
> 0000030004a09680      1 z1                   /opt/zones/z1/root/
> 0000030004a09680      1 z1                   /opt/zones/z1/root/
> 0000030004a09680      1 z1                   /opt/zones/z1/root/
> 0000030004a09680      1 z1                   /opt/zones/z1/root/
>
> So if each of those rnodes has two holds on the zone, then that accounts
> for
> all of the extra holds exactly.
>
>
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org

Reply via email to