OT - was Hammer or ZFS based backup, encryption

[Bill Hacker]

Michael Neumann wrote:
Am Sat, 21 Feb 2009 19:17:11 -0800
schrieb Jeremy Chadwick <jdc at parodius.com>:
On Sun, Feb 22, 2009 at 11:59:57AM +1100, Dmitri Nikulin wrote:
On Sun, Feb 22, 2009 at 10:34 AM, Bill Hacker <wbh at conducive.org>
wrote:
Hopefully more 'good stuff' will be ported out of Solaris before
it hits the 'too costly vs the alternatives' wall and is orphaned.
Btrfs has been merged into mainline Linux now, and although it's
pretty far behind ZFS in completeness at the moment, it represents a
far greater degree of flexibility and power. In a couple of years
when it's stable and user friendly, high-end storage solutions will
move back to Linux, after having given Sun a lot of contracts due
specifically to ZFS.
The fact that btrfs offers grow/shrink capability puts it ahead of ZFS
with regards to home users who desire a NAS.  I can't stress this
point enough.  ZFS's lack of this capability limits its scope.  As it
stands now, if you replace a disk with a larger one, you have to go
through this extremely fun process to make use of the new space
available:
- Offload all of your data somewhere (read: not "zfs export"); rsync
  is usually what people end up using -- if you have multiple ZFS
  filesystems, this can take some time
- zpool destroy
- zpool create
- zfs create
And if you add a new disk to the system, it's impossible to add that
disk to the existing pool -- you can, of course, create an entirely
new zpool which uses that disk, but that has nothing to do with the
existing zpool.  So you get to do the above dance.
Hm, I thought that would work easily with ZFS, and at least in theory I
think that should work well with ZFS. Or what is wrong with:
  zpool add tank /dev/ad8s1

Okay "zpool remove" doesn't seem to work as expected, but it should
work well at least for RAID-1 (which probably no one uses for large
storage systems ;-). Maybe "zfs replace" works, if you replace an old
disk, with a larger disk, and split it into two partitions, the one
equally sized to the old, and the other containing the remainder of the
space. Then do:
  zfs replace tank old_device new_device_equally_sized
  zfs add tank new_device_remainder
But you probably know more about ZFS than me ;-)

As for Hammer, I worked on some patches that will allow it to expand a
Hammer FS while mounted. It's actually very easy to implement (~100
LoC). And the shrink case should be at least in theory pretty easy to
implement, thanks to reblocking. So with very little work, we can make
Hammer grow/shrink natively (maybe it's in the next release). 

Regards,

  Michael
Side issue again - just brought up DFLY 2.3.0, default all-hammer layout.

- atop a natacontrol RAID1 on a pair of salvaged 60 GB IBM 'Deathstars'.

- VIA C7 1.5 GHz CPU (the el-cheapo MB aimed at Wal-Mart)

- pulled half the RAM, leaving only 1GB

Periodically, the aged IBM's sound like squirrels having a go in a 
gravel pit, Xfce4 is *very* slow, but it hadn't started swapping, and 
based on what 'top' is showing should actually work decently for basic 
file, web, or mail serving, especially as the OpenSSL recognizes the VIA 
padlock engine.  Planty fast enough with 2GB, BTW.

ZFS is not famed for tolerating that meagre a resource ration as well as 
HAMMER....

Hardly a scientific test, but I can go off and grab lunch while 
OpenSolaris and ZFS boot to a GUI on 2 to 4 GB of RAM and a Core-D 2.6 
GHz and 'recent' WD SATA drives.

Not sure I have enough years left to try it on the VIA - at least 'til I 
can get the 64-bit Nano...

;-)

Bill