On Tue, Sep 13, 2011 at 3:31 PM, Paul B. Henson <hen...@acm.org> wrote:
> Did update 10 sneak out under cover of darkness or what? I didn't see
> any announcements or chatter about it, google doesn't find anything, and
> the Oracle download site still only shows update 9:
It was supposed to be released on August 17, but I have not had
support point me at it yet. I suspect (based on some chatter) that
they found a bug that has forced them back to the drawing board for a
few weeks.
>> Thank you for flagging this, as Oracle support is telling me I have
>> to update to this release to get zpool 26 which fixes a zfs bug we
>> are running into, but if it breaks the ACL inheritance we have been
>> using, then it is non-starter.
>
> Yup. Fortunately, there are no critical bugs (that Oracle is willing to
> fix 8-/) that I've been waiting for. I thought I'd be able to keep an
> up-to-date S10 install going while I figure out what to do next; guess
> not :(.
Uhhh, not being able to destroy snapshots that are "too big" is a
pretty big one for us :-(
> He already opened a support ticket, they responded:
>
> -----
> ZFS appears to be the only file system supporting NFSv4 ACLs
> that attempts to preserve ACLs during chmod(2) operations.
> Unfortunately, this requires the ACL to be modified in ways that are
> confusing to customers and the time has come to stop the confusion and to
> just "discard" the ACL during chmod(2) operations. This implies that the ZFS
> aclmode property will no longer be needed and will be removed from ZFS.
So the default behavior will be aclmode = discard, wonderful as
that will probably seriously break what I am working on right now.
> This functionality is targetted to be back in Solaris 11 - as per
> CR7002239 want ZFS aclmode property back
> -----
>> runs the system out of RAM. The snapshot is a partial zfs recv. I am
>> told this is a known bug (destruction of large snapshots can run the
>> system out of RAM as the destroy operation commits as one TXG). There
>> is a fix, but it in the on-disk format, so just zpool upgrading to
>> version 26 will not fix existing snapshots. We only have 32 GB in
>> this system and the faulty snapshot *should* be about 2.5 TB.
>
> Hmm, if updating the zpool won't fix the existing snapshot, how is support
> telling you to recover? Is it going to be one of those wipe and rebuild
> resolutions 8-/? Good luck...
I am having that discussion with Oracle Support right now :-) One
option is to load the system with enough RAM to destroy the legacy
snapshots and then not let them grow too big (in other words, take
more frequent snapshots). But I have been having trouble getting
support to tell me how to estimate the amount of RAM necessary to
delete a snapshot based on *something* I can measure.
P.S. The backup server ran into the bug full steam ahead and is off
line right now. On production, once I realized the root cause I
stopped the snapshot destroy script, so they are just piling up now
:-) Production is 20 TB and 400 million objects, we can't reload that,
the outage would kill us.
--
{--------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
