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

[Michael Neumann <mneumann@xxxxxxxx>]

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