Re: [zfs-discuss] aclmode gone in S10u10?
On 09/14/11 08:49 PM, Sami Ketola wrote: On Sep 13, 2011, at 3:21 , Peter Tribble wrote: On Tue, Sep 13, 2011 at 1:50 AM, Paul B. Hensonhen...@acm.org wrote: I recently saw a message posted to the sunmanagers list complaining about installing a kernel patch and suddenly having his ACL's disappear completely whenever a chmod occurred. I replied and asked him to check if the aclmode attribute was gone, as it sounded like the default discard that was (questionably) implemented in OpenSolaris/Solaris 11. He confirmed it was, so it looks like the removal of aclmode was backported to Solaris 10? I don't know exactly what kernel patch he installed; it doesn't look like update 10 is out yet. Update 10 has been out for about 3 weeks. No it has not. As of now Solaris 10 u10 has not been released. It slipped out the back door for a couple of days a few weeks ago. -- Ian. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] booting from ashift=12 pool..
Hi, On Mon, Sep 05, 2011 at 02:18:48AM -0400, Daniel Carosone wrote: I see via the issue tracker that there have been several updates since, and an integration back into the main Illumos tree. How do I go about getting hold of current boot blocks? The OpenIndiana release that was announced earlier today has the fixed boot blocks. Hans -- %SYSTEM-F-ANARCHISM, The operating system has been overthrown ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] zfs destroy snapshot runs out of memory bug
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).
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).
--
{1-2-3-4-5-6-7-}
Paul Kraus
- Senior Systems Architect, Garnet River ( http://www.garnetriver.com/ )
- Sound Designer: Frankenstein, A New Musical
(http://www.facebook.com/event.php?eid=123170297765140)
- Sound Coordinator, Schenectady Light Opera Company (
http://www.sloctheater.org/ )
- Technical Advisor, RPI Players
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs destroy snapshot runs out of memory bug
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
Re: [zfs-discuss] zfs destroy snapshot runs out of memory bug
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
[zfs-discuss] Is there any implementation of VSS for a ZFS iSCSI snapshot on Solaris?
I am using a Solaris + ZFS environment to export a iSCSI block layer device and use the snapshot facility to take a snapshot of the ZFS volume. Is there an existing Volume Shadow Copy (VSS) implementation on Windows for this environment? Thanks S Joshi ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs destroy snapshot runs out of memory bug
On Wed, Sep 14, 2011 at 4:31 PM, Richard Elling
richard.ell...@gmail.com wrote:
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?)
T2000 with 32 GB RAM
zpool that hangs the machine by running it out of kernel memory when
trying to import the zpool
zpool has an incomplete snapshot from a zfs recv that it is trying
to destroy on import
I *can* import the zpool readonly
So the answer is yes to the severe memory shortfall. One of the
many things I did to instrument this system was as simple as running
vmstat 10 on the console :-) The last instance before the system hung
showed a scan rate of 900,000 ! In one case I watched as it hung (it
has done this many times as I have troubleshot with Oracle Support)
and did not see *any* user level processes that would account for the
memory shortfall. I have logs of system freemem showing the memory
exhaustion. Oracle Support has confirmed (from a core dump) that it is
some combination of the two bugs you mentioned (plus they created a
new Bug ID for this specific problem).
I have asked multiple times if the incomplete snapshot could be
corrupt in a way that would cause this (early on then led us to
believe the incomplete snapshot was 7 TB when it should be about 2.5
TB), but have not gotten anything substantive back (just a one line,
The snapshot is not corrupt.).
What I am looking for is a way to estimate the kernel memory
necessary to destroy a given snapshot so that I can see if any of the
snapshots on my production server (M4000 with 16 GB) will run the
machine out of memory.
--
{1-2-3-4-5-6-7-}
Paul Kraus
- Senior Systems Architect, Garnet River ( http://www.garnetriver.com/ )
- Sound Designer: Frankenstein, A New Musical
(http://www.facebook.com/event.php?eid=123170297765140)
- Sound Coordinator, Schenectady Light Opera Company (
http://www.sloctheater.org/ )
- Technical Advisor, RPI Players
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] booting from ashift=12 pool..
On Wed, Sep 14, 2011 at 04:08:19PM +0200, Hans Rosenfeld wrote: On Mon, Sep 05, 2011 at 02:18:48AM -0400, Daniel Carosone wrote: I see via the issue tracker that there have been several updates since, and an integration back into the main Illumos tree. How do I go about getting hold of current boot blocks? The OpenIndiana release that was announced earlier today has the fixed boot blocks. Yep, saw that and have it here ready to boot and install grub. I hope the fact that the pool itself is v31 for zfs crypto will not be a problem.. If it should be the case that the pool version is an issue running from the OI CD, can I take the updated stage* files and use them with the installgrub from solaris express b151? I guess I'll find out in due course. -- Dan. pgph7UOuW8sMw.pgp Description: PGP signature ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs destroy snapshot runs out of memory bug
On Wed, Sep 14, 2011 at 05:36:53PM -0400, Paul Kraus wrote: T2000 with 32 GB RAM zpool that hangs the machine by running it out of kernel memory when trying to import the zpool zpool has an incomplete snapshot from a zfs recv that it is trying to destroy on import I *can* import the zpool readonly Can you import it booting from a newer kernel (say liveDVD), and allow that to complete the deletion? Or does this not help until the pool is upgraded past the on-disk format in question, for which it must first be imported writable? If you can import it read-only, would it be faster to just send it somewhere else? Is there a new-enough snapshot near the current data? -- Dan. pgpSAJqkjQOd1.pgp Description: PGP signature ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
