On Sep 14, 2011, at 12:07 PM, Paul Kraus wrote:
> 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
>> 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
>> 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
> 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.
Did you experience a severe memory shortfall?
(Do you know how to determine that condition?)
zfs-discuss mailing list