Question below… 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 >> 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 > -or- > 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?) -- richard _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
