On Sep 14, 2011, at 9:50 AM, Paul Kraus 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
> list archives and on defects.opensolaris.org I cannot find it. Could
> someone here explain the failure mechanism in language a Sys Admin (I
> am NOT a developer) could understand. I am running Solaris 10 with
> zpool 22 and I am looking for both understanding of the underlying
> problem and a way to estimate the amount of kernel memory necessary to
> destroy a given snapshot (based on information gathered from zfs, zdb,
> and any other necessary commands).
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
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.
> Thanks in advance, and sorry to bring this up again. I am almost
> certain I saw mention here that this bug is fixed in Solaris 11
> Express and Nexenta (Oracle Support is telling me the bug is fixed in
> zpool 26 which is included with Solaris 10U10, but because of our use
> of ACLs I don't think I can go there, and upgrading the zpool won't
> help with legacy snapshots).
Sorry, I haven't run Solaris 10 in the past 6 years :-) can't help you there.
But I can say that NexentaStor has this bug fix in 3.0.5. For NexentaStor 3.1+
releases, zpool version is 28.
zfs-discuss mailing list