zfs discuss - Jun 2010 - ZFS bug - should I be worried about this?

I found this today:

http://blog.lastinfirstout.net/2010/06/sunoracle-finally-announces-zfs-data.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+LastInFirstOut+%28Last+In%2C+First+Out%29&utm_content=FriendFeed+Bot

How can I be sure my Solaris 10 systems are fine?
Is latest OpenSolaris (134) safe?

Thx
Gabriele.
-- 
This message posted from opensolaris.org

On 06/28/10 08:15 PM, Gabriele Bulfon wrote:
> I found this today:
>
>
http://blog.lastinfirstout.net/2010/06/sunoracle-finally-announces-zfs-data.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+LastInFirstOut+%28Last+In%2C+First+Out%29&utm_content=FriendFeed+Bot
>
> How can I be sure my Solaris 10 systems are fine?
> Is latest OpenSolaris (134) safe?
>    
Did you read the Sunsolve document?

b134 is not vulnerable.

-- 
Ian.

Yes, I did read it.
And what worries me is patches availability...
-- 
This message posted from opensolaris.org

mmm....I double checked some of the running systems.
Most of them have the first patch (sparc-122640-05 and x86-122641-06), but not
the second one (sparc-142900-09 and x86-142901-09)...

...I feel I''m right in the middle of the problem...
How much am I risking?! These systems are all mirrored via zpool...

Would this really make me safe without patching?? :

    set zfs:zfs_immediate_write_sz=1000000000
    set zfs:zvol_immediate_write_sz=1000000000

Or a Log would be preferred?

*sweat*
These systems are all running for years now....and I considered them safe...
Have I been at risk all this time?!
-- 
This message posted from opensolaris.org

On 28-6-2010 12:13, Gabriele Bulfon wrote:
> *sweat*
> These systems are all running for years now....and I considered them
safe...
> Have I been at risk all this time?!
They''re still running, are they not? So, stop sweating. <g>
But you''re right about the changed patching service from Oracle.
It sucks big time. Safety patches should be available, even it the OS is 
free. You can''t expect users to run unsafe systems just because they 
have not payed for the OS. After all, it''s Oracle (SUN) who gives away 
the OS.

-- 
+ All that''s really worth doing is what we do for others (Lewis Carrol)

Yes...they''re still running...but being aware that a power failure
causing an unexpected poweroff may make the pool unreadable is a pain....

Yes. Patches should be available.
Or adoption may be lowering a lot...
-- 
This message posted from opensolaris.org

On 28.06.10 16:16, Gabriele Bulfon wrote:
> Yes...they''re still running...but being aware that a power failure
causing an
> unexpected poweroff may make the pool unreadable is a pain....
Pool integrity is not affected by this issue.

Oh well, thanks for this answer.
It makes me feel much better!
What are eventual risks?
Gabriele Bulfon - Sonicle S.r.l.
Tel +39 028246016 Int. 30 - Fax +39 028243880
Via Felice Cavallotti 16 - 20089, Rozzano - Milano - ITALY
http://www.sonicle.com
----------------------------------------------------------------------------------
Da: Victor Latushkin
A: Gabriele Bulfon
Cc: zfs-discuss at opensolaris.org
Data: 28 giugno 2010 16.14.12 CEST
Oggetto: Re: [zfs-discuss] ZFS bug - should I be worried about this?
On 28.06.10 16:16, Gabriele Bulfon wrote:
Yes...they''re still running...but being aware that a power failure
causing an
unexpected poweroff may make the pool unreadable is a pain....
Pool integrity is not affected by this issue.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100628/d182ed44/attachment.html>

On Mon, 2010-06-28 at 05:16 -0700, Gabriele Bulfon
wrote:
> Yes...they''re still running...but being aware that a power failure
causing an unexpected poweroff may make the pool unreadable is a pain....
> 
> Yes. Patches should be available.
> Or adoption may be lowering a lot...

I don''t have access to the information, but if this problem is the same
one I think it is, then the pool does not become unreadable.  Rather,
its state after such an event represents a *consistent* state from some
point of time *earlier* than that confirmed fsync() (or a write on a
file opened with O_SYNC or O_DSYNC).

For most users, this is not a critical failing.  For users using
databases or requiring transactional integrity for data stored on ZFS,
then yes, this is a very nasty problem indeed.

I suspect that this is the problem I reported earlier in my blog
(http://gdamore.blogspot.com) about certain kernels having O_SYNC and
O_DSYNC problems.  I can''t confirm this though, because I
don''t have
access to the SunSolve database to read the report.

(This is something I''ll have to check into fixing... it seems like my
employer ought to have access to that information...)

	- Garrett