zfs discuss - Jun 2007 - Problem in v3 on Solaris 10 and large volume mirroring

Solaris 10, u3, zfs 3 kernel 118833-36.

 Running into a weird problem where I attach a mirror to a large, existing
filesytem. The attach occurs and then the system starts swallowing all the
available memory and the system performance chokes, while the filesystems sync.
In some cases all memory goes away and the system becomes unresponsive. If the
system is left to itself for the time it should take to sync the disks, the sync
doesn''t occur. It can ping but won''t allow logins, even from
console. So I break the system (a v490) to PROM, boot -s and when the system
comes up the mirror starts resilvering (from 0%), available memory goes to 230mb
(from 32GB) at the rate of about 1GB/15 secs and then hops up to 4GB when it
hits bottom. I let the system alone and allow the sync to complete, all the
while having really slow console access. zpool status will show that the pool is
in a good state, then I allow the system to come up to level 3 by exiting
console, the sync of the mirror restarts at level 3, zpool status shows the
mirror resilvering and the system begins the memory swallowing and goes into an
unusable state, without even console access.
 
 
This message posted from opensolaris.org

JS wrote:
> Solaris 10, u3, zfs 3 kernel 118833-36.
> 
>  Running into a weird problem where I attach a mirror to a large, existing
filesytem. The attach occurs and then the system starts swallowing all the
available memory and the system performance chokes, while the filesystems sync.
In some cases all memory goes away and the system becomes unresponsive. If the
system is left to itself for the time it should take to sync the disks, the sync
doesn''t occur. It can ping but won''t allow logins, even from
console. So I break the system (a v490) to PROM, boot -s and when the system
comes up the mirror starts resilvering (from 0%), available memory goes to 230mb
(from 32GB) at the rate of about 1GB/15 secs and then hops up to 4GB when it
hits bottom. I let the system alone and allow the sync to complete, all the
while having really slow console access. zpool status will show that the pool is
in a good state, then I allow the system to come up to level 3 by exiting
console, the sync of the mirror restarts at level 3, zpool status shows
 the mirror resilvering and the system begins the memory swallowing and goes
into an unusable state, without even console access.

This is bug 6456888, fixed in snv_60 and s10u4.

--matt