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