Re: [CFT] ZFS v15 patch (version 3)

From: Jason J. W. Williams <jasonjwwilliams_at_gmail.com>
Date: Thu, 8 Jul 2010 13:19:01 -0600
Hi Martin,

If 15 is the only one that will make it into FBSD9 then obviously
that's better than doing nothing.

I'll contact my folks on the ZFS dev team at Sun to pull the DB
enhancements and related ZFS versions.

-J

On Thu, Jul 8, 2010 at 3:06 AM, Martin Matuska <mm_at_freebsd.org> wrote:
> Hi Jason,
>
> as for me, I am ready to stand for the stability of my v15 upgrade, it
> has been discussed with our zfs team, and we also see it as a kind of a
> starting point.
>
> We generally have two options:
> a) push ZFS v15 now
> - it has been already disussed
> - we can continue with incremental upgrades that do bugfixes or
> introduce non-intrusive features like we did until now
> - upgrade to higher versions in the future
>
> b) do not push anything, wait for a uncertain ammount of time and import
> a higher version
> -  this might take months or even more than 1 year
> - our project is not an anarchy or a dictatorship, so it has to be
> argued, discussed, evaluated and publicly tested again
>
> As for me, I go for a).
>
> The recent ZFS code contains even more OpenSolaris specific parts, zvol
> code probably needs to be reprogrammed once again and there are also
> other features like autoexpansion of pools that need polishing. If you
> want some future information, there are plans and already work to make
> the very latest ZFS available. But its uncertainity again, I cannot give
> you any dates but what is very probable that you won't see anything that
> early. Of course any volunteers that are willing to help us porting ZFS
> features are welcome :-)
>
> Now to the performance fixes for DB workloads - can you point me to the
> code or tell me what do they do?
> We have already now the prefetch improvements from v19 and ARC
> improvements from v15 in stable/8.
> Many parts of the OpenSolaris code can be very easily integrated without
> breaking existing stuff and again, v15 is a very good starting point for
> this.
>
> Regarding performance, e.g. my PHP web servers with codebase in ZFS
> yield 15-20% more req/s with v15 patch (as compared to v14).
>
> Cheers,
> mm
>
> Dňa 8. 7. 2010 9:47, Jason J. W. Williams  wrote / napísal(a):
>> Hi Martin,
>>
>> If you're using it for NFS then that can be a good feature, but I see a lot more folks complaining about lack of removal for log devices.
>>
>> We've been using ZFS on OpenSolaris for DB servers since 2006 and OpenSolaris bits are very stable. In most cases we've found ZFS under OSol to be more stable than Solaris. Normally this is due to the youth of ZFS and the speed with which bugs are being corrected...which end up in OSol while Solaris languishes under it's long release cycle.  I'll posit Joyent as an example here of the stability of OSol bits...they use the SXCE distro recently discontinued.
>>
>> v19 also includes a number of performance fixes for DB workloads.
>>
>> -J
>>
>> Sent via iPhone
>>
>> Is your e-mail Premiere?
>>
>> On Jul 8, 2010, at 1:32, Martin Matuska <mm_at_FreeBSD.org> wrote:
>>
>>
>>> User and group quotas is no important enhancement?
>>>
>>> We have to see the whole thing from a stability perspective as well -
>>> OpenSolaris has by far less testing than Solaris 10.
>>> Oracle cannot afford to feed his enterprise customers (and these are not
>>> few) with untested code.
>>>
>>> Dňa 7. 7. 2010 20:30, Sam Fourman Jr. wrote / napísal(a):
>>>
>>>> On Wed, Jul 7, 2010 at 1:25 PM, Jason J. W. Williams
>>>> <jasonjwwilliams_at_gmail.com> wrote:
>>>>
>>>>
>>>>> If the target is FreeBSD 9 instead of 8.1, why not merge ZFS v19? 15
>>>>> really doesn't give any major enhancements over 14 and FreeBSD 9 isn't
>>>>> coming out any time.
>>>>>
>>>>> 19 would give much need log device removal and triple parity RAID-Z.
>>>>> Both of which are well tested at this point via OpenSolaris.
>>>>>
>>>>>
>>>>>
>>>> these are very valid points, but I am not sure that anyone has zfs v19 patches
>>>>
>>>>
>>>>
>
Received on Thu Jul 08 2010 - 17:19:09 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:05 UTC