On Wed, Sep 14, 2011 at 2:30 PM, Richard Elling
<richard.ell...@gmail.com> wrote:

> I don't recall a bug with that description. However, there are several bugs 
> that
> relate to how the internals work that were fixed last summer and led to the
> on-disk format change to version 26 (Improved snapshot deletion performance).
> Look for details 
> in http://src.illumos.org/source/history/illumos-gate/usr/src/uts/common/fs/zfs/
> during the May-July 2010 timeframe. Methinks the most important change was
> 6948890 snapshot deletion can induce pathologically long spa_sync() times
> spa_sync() is called when the transaction group is sync'ed to permanent 
> storage.

I looked through that list, and found the following that looked applicable:
6948911 snapshot deletion can induce unsatisfiable allocations in txg sync
6948890 snapshot deletion can induce pathologically long spa_sync() times

But all I get at bugs.opensolaris.org is a Service Temporarily
Unavailable message (and have for at least the past few weeks). The
MOS lookup of the 6948890 bug yields the title and not much else, no
details. I can't even find the 6948911 bug in MOS.

MOS == My Oracle Support

Thanks for the pointers, I just wish I could find more data that will
lead me to either:
A) a mechanism to estimate the RAM needed to destroy a pre-26 snapshot
B) indication that there is no way to do A.

>From watching the system try to import this pool, it looks like it is
still building a kernel structure in RAM when the system runs out of
RAM. It has not committed anything to disk.

Paul Kraus
-> Senior Systems Architect, Garnet River ( http://www.garnetriver.com/ )
-> Sound Designer: Frankenstein, A New Musical
-> Sound Coordinator, Schenectady Light Opera Company (
http://www.sloctheater.org/ )
-> Technical Advisor, RPI Players
zfs-discuss mailing list

Reply via email to