On Sun, Oct 30, 2011 at 5:13 PM, Jim Klimov <jimkli...@cos.ru> wrote:
>> I know there was (is ?) a bug where a zfs destroy of a large
>> snapshot would run a system out of kernel memory, but searching the
> Symptoms are like what you've described, including the huge scanrate
> just before the system dies (becomes unresponsive). Also if you try running
> with "vmstat 1" you can see that in the last few seconds of
> uptime the system would go from several hundred free MBs (or even
> over a GB free RAM) down to under 32Mb very quickly - consuming
> hundreds of MBs per second.
That is the traditional symptoms of a Solaris kernel memory bug :-)
> Unlike your system, my pool started with ZFSv28 (oi_148a), so any
> bugfixes and on-disk layout fixes relevant for ZFSv26 patches are
> in place already.
Ahhh, but jumping to the end...
> In my case I saw that between reboots and import attempts this
> counter went down by some 3 million blocks every uptime, and
> after a couple of stressful weeks the destroyed dataset was gone
> and the pool just worked on and on.
So your pool does have the fix. With zpool 22 NO PROGRESS is made
at all with each boot-import-habg cycle. I have an mdb command that I
got from Oracle support to determine the size of the snapshot that is
being destroyed. The bug in 22 is that a snapshot destroy is committed
as a single TXG. In 26 this is fixed (I assume there are on disk
checkpoints to permit a snapshot to be destroyed in multiple TXG).
How big is / was the snapshot and dataset ? I am dealing with a 7
TB dataset and a 2.5 TB snapshot on a system with 32 GB RAM. Oracle
has provided a loaner system with 128 GB RAM and it took 75 GB of RAM
to destroy the problem snapshot). I had not yet posted a summary as we
are still working through the overall problem (we tripped over this on
the replica, now we are working on it on the production copy).
--
{--------1---------2---------3---------4---------5---------6---------7---------}
Paul Kraus
-> Senior Systems Architect, Garnet River ( http://www.garnetriver.com/ )
-> Sound Coordinator, Schenectady Light Opera Company (
http://www.sloctheater.org/ )
-> Technical Advisor, RPI Players
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
