[CALUG] Fwd: November 13 Meeting Announcement - ZFS Overview

[Randal T. Rioux]

Thanks for the follow-up. Great info. I'll go check out the slides.

I *just* setup ZFS on RHEL (my new 10Gbe NICs don't support FreeBSD, so
this is quite timely!). Excited to see how the project has come along.


On 11/16/2013 7:05 PM, Keith wrote:
> My apologies Randal, I forgot to forward along Eric's answers to your
> questions to the list.
> The presentation's slides are available on the CALUG website.
> 
> ---------- Forwarded message ----------
> From: *Eric Sproul* <esproul at omniti.com <mailto:esproul at omniti.com>>
> Date: Thu, Nov 7, 2013 at 1:41 PM
> Subject: Re: [CALUG] November 13 Meeting Announcement - ZFS Overview
> To: Keith <keith at keithf4.com <mailto:keith at keithf4.com>>
> 
> 
> I'll answer the questions as best I can and let you forward them back
> to the list.
> 
> On Thu, Nov 7, 2013 at 12:13 PM, Keith <keith at keithf4.com
> <mailto:keith at keithf4.com>> wrote:
>>
>>
>> ---------- Forwarded message ----------
>> From: Randal T. Rioux <randy at procyonlabs.com
> <mailto:randy at procyonlabs.com>>
>> Date: Wed, Nov 6, 2013 at 12:08 AM
>> Subject: Re: [CALUG] November 13 Meeting Announcement - ZFS Overview
>> To: calug at unknownlamer.org <mailto:calug at unknownlamer.org>
> 
> 
>> One thing that attracted me is the snapshot capability, and that I can
>> set gzip-7 at the filesystem level (avg 1.18x compression right now!)
>> and transfer are actually *faster* with compression on :-)
> 
> This is true, because most file servers have CPU cycles to spare, and
> trading extra CPU for reduced IOPS is almost always a win.  I'd note
> that with mostly uncompressable data (1.18x would qualify), the
> default compression algorithm (lzjb) will likely be even faster than
> gzip, especially at level 7.  The more recent addition of lz4 should
> be faster still, especially on uncompressable data.
> 
> I'll be covering compression options in the talk.
> 
>> One quick one now if you don't mind before the talk: what is the best
>> way to schedule a snapshot regimen for 1, 3, 7 and 30 days including
>> destroying old ones? I see scripts and stuff on the Web, but they all
>> look different and seem to over complicate things.
> 
> "Best way" invites lots of opinions, so I'll simply say that snapshots
> may be created at will and destroyed without respect to sequence.  So
> you can take snapshots at some minimum interval, then later on make a
> decision about which ones to keep or delete.
> 
>>
>> Tangent: can you tell us more about OmniOS (online info is scarce) and
>> whether Circonus is purely commercial (appears so)?
> 
> OmniOS is a distribution of illumos (http://illumos.org) which is an
> open-source fork of the former OpenSolaris codebase.  It is a
> minimalist distribution aimed at traditional enterprise server
> deployments.  The mission statement is here:
> http://omnios.omniti.com/wiki.php/OmniOSJeOS and contains a link to
> Theo's LISA'12 talk, "OmniOS Motivation and Design".
> 
> Circonus is indeed a commercial product, but the metrics collection
> engine that it uses is the open-source Reconnoiter project:
> https://github.com/circonus-labs/reconnoiter
> 
> Eric
> 
> 
> 
> _______________________________________________
> CALUG mailing list
> CALUG at unknownlamer.org
> http://lists.unknownlamer.org/listinfo/calug
>