Re: OT - was Hammer or ZFS based backup, encryption

[Bill Hacker <wbh@xxxxxxxxxxxxx>]

Michael Neumann wrote:
> Am Sat, 21 Feb 2009 19:17:11 -0800
> schrieb Jeremy Chadwick <jdc@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@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