Impossible compression ratio on ZFS

[jhell]

On Fri, Jun 17, 2011 at 10:10:26AM +0100, krad wrote:
> On 13 June 2011 23:50, Steven Hartland <killing at multiplay.co.uk> wrote:
> 
> >
> > ----- Original Message ----- From: "jhell" <jhell at DataIX.net>
> > To: "Steven Hartland" <killing at multiplay.co.uk>
> > Cc: "Jeremy Chadwick" <freebsd at jdc.parodius.com>; <freebsd-fs at freebsd.org>
> > Sent: Monday, June 13, 2011 8:35 PM
> >
> > Subject: Re: Impossible compression ratio on ZFS
> >
> >>
> >>
> >  Hi Steve,
> >>
> >> Knowing that there were patches out for v28 on 8.X can you confirm that
> >> in fact you are using v15 ZFS ? I would assume you are because of the
> >> release but I don't want to do that.
> >>
> >
> > Confirmed this is a pure 8.2 release build machine no additional patches
> > except for compiling libz without assembly optimisations as thats known
> > to cause crashes.
> >
> > Specifically the following as directed by Xin LI:-
> > cd /usr/src/lib/libz
> > make cleandir
> > make cleandir (yes, do it the second time)
> > make MACHINE_ARCH=x86_64 obj depend all
> > make MACHINE_ARCH=x86_64 install
> >
> >
> >
> >  If not, then seeing you have compression turned on... did you  just dump
> >> that whole table into the database ? its quite possible that the
> >> compression was still happening in ARC before it was finally written out
> >> and this would also explain why that happened.
> >>
> >
> > The table was just rebuilt due to changing an index, so in effect yes
> > the data would have been copied from the old table into a fresh new copy
> > and then renamed.
> >
> >
> >  Also what level of compression are you using ?
> >>
> >
> > Standard lzjb, which is achieving 1.9 overall and 2.45 on this table file.
> >
> > Does indeed sound like this data was still being processed in some way but
> > surprised it took quite so long to show something other than the initial
> > file
> > creation size.
> >
> > Its not a big issue in this case, but does raise concerns that if it wasn't
> > showing the "correct" file size that the data may not have been commited to
> > disk, hence could have been unsafe for this quite extended period.
> >
> > Setting that may be relavent in the case within mysql are:-
> > innodb_log_file_size = 1024M
> > innodb_log_buffer_size = 8M
> > innodb_flush_method = O_DIRECT
> > innodb_use_native_aio = 1
> >
> > So its possible that the table was in the innodb log, but I've never
> > witnessed that before tbh but its also only very recently we have moved
> > our db server from ufs to zfs, hence the questions.
> >
> >
> >   Regards
> >   Steve
> >
> >
> >
> > ==============================**==================
> > This e.mail is private and confidential between Multiplay (UK) Ltd. and the
> > person or entity to whom it is addressed. In the event of misdirection, the
> > recipient is prohibited from using, copying, printing or otherwise
> > disseminating it or any information contained in it.
> > In the event of misdirection, illegible or incomplete transmission please
> > telephone +44 845 868 1337
> > or return the E.mail to postmaster at multiplay.co.uk.
> >
> > ______________________________**_________________
> > freebsd-fs at freebsd.org mailing list
> > http://lists.freebsd.org/**mailman/listinfo/freebsd-fs<http://lists.freebsd.org/mailman/listinfo/freebsd-fs>
> > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@**freebsd.org<freebsd-fs-unsubscribe at freebsd.org>
> > "
> >
> 
> is that cvs'd to release or stable though? If stable when? zfs v28 was
> commited to stable a week or so ago. Do a 'zpool upgrade' to check

I think its safe to say that by Steve's reply if youve been following
that it is v15.