OT - was Hammer or ZFS based backup, encryption

[Bill Hacker]

22215619.GA43400 at icarus.home.lan>
In-Reply-To: <20090222215619.GA43400 at icarus.home.lan>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 94
Message-ID: <49a23146$0$880$415eb37d at crater_reader.dragonflybsd.org>
NNTP-Posting-Host: 61.10.57.144
X-Trace: 1235366216 crater_reader.dragonflybsd.org 880 61.10.57.144
Xref: crater_reader.dragonflybsd.org dragonfly.users:12026

Jeremy Chadwick wrote:
> On Mon, Feb 23, 2009 at 04:53:35AM +0800, Bill Hacker wrote:
>> Jeremy Chadwick wrote:
>>
>> *snip*
>>
>>> The problem I was attempting to describe: all pool members must be the
>>> same size, otherwise all members are considered to be equal to the size
>>> of the smallest.  In English: you cannot "mix-and-match" different sized
>>> disks.
>>>
>> *TILT*
>>
>> C'mon guys - that has nuthin to do with ZFS or any other RAID [1].
>>
>> {snip}
> 
> Circling back to the near-start of the thread (specifically Dmitri's
> comment): the point was that Linux has btrfs and a few other filesystems
> that offer some really fantastic features (including what I've
> described).  Commercial filers (see: Network Appliance, Pillar Axiom)
> also offer mix-matched disk sizes and grow/shrink capability.  (NetApp
> is actually based on BSD, but naturally all the FS stuff is proprietary)
> 
> How/why does this matter to us?
> 
> Because users are commonly using *BSD as a form of inexpensive filer for
> their servers (not everyone can afford a NetApp or Axiom), or as an OS
> on their home NAS (which includes pfSense and m0n0wall).  In both of
> these cases, expanding/growing the array isn't possible, which greatly
> limits the user-base scope -- and sadly, users usually don't find this
> out until they've already made their choice, swap/upgrade a disk, then
> post "WTF!" on a mailing list or forum somewhere.
> 
> ZFS happens to be incredibly easy to manage (from an administrative POV)
> and solves many shortcomings.  It's significantly easier to understand
> and use than Linux LVM (Linux md/mdadm is simple, it's the LVM part that
> adds excessive complexity).  HAMMER also appears to be pretty easy to
> manage and also solves many shortcomings, in a significantly different
> way than ZFS (obviously).  These are excellent improvements in the BSD
> world, but there's still a few things folks really want which will
> ultimately improve on what BSD is being used for today.  That's all I'm
> trying to say.  :-)
> 

Well said ..

With the improvements in reliability of HDD, redundancy in the HDD 
within any one given box is no longer our 'hot spot' - and may never be 
again.

A SAN or NAS doesn't improve that - it potentially makes it worse w/r 
single point of failure.

Going forward, it makes more sense to *us* drop each of our 
traditionally RAID1 or RAID5 boxes to multiple, but non-RAID HDD, 
connect the boxen to each other with Gig-E or better, and let each 
support the redundancy for one or more of the others.

Lower risk of outage from CPU or PSU fan failures... or 'fat fingers'.
Potential for IP-failover HA configuration.

Hence my testing as to how happy HAMMER is with lowly C3, (fair), C7 
(quite decent), C9/Nano ('to do' but should be as good as it needs to 
be... 'gamers' or GUI-centric we are not).

. .and the research on Gfarm, Gluster, Dfarm, Chiron, Seph ... yada, 
yada... But Linux - where most of these distributed tools presently 
perch - is just not an option for *our* use. 'Wetware' cost is too high.

FreeBSD's GEOM/GMIRROR has had the counterpart to hammer mirror-stream 
over the link for quite some time. But UFS(2) only, and while that fs 
has never done me any harm, 'snapshots' on UFS are an add-on, not inherent.

Enter HAMMER.... not because it is necessarily any better (yet) than 
some form of 'grid farm' w/r distributed storage....

. .. but because HAMMER was optimized from the ground up for inherent 
ease of snapshot management, and to a higher degree than anything else 
since FOSSIL/VENTI - which did not scale well.....and *did* break now 
and then.

Likewise, hammer mirror-stream (so far) looks to be very good at steady, 
working - not likely to overload the primary or the b/w.

JM2CW, but I suspect we are not alone in wanting to stop sending so many 
RAID HDD that haven't actually failed to the landfill.

Or paying to heat a CPU, head-positioner, and NIC with constant rsyncing 
calculations.

JM2CW

Bill