Am Sat, 21 Feb 2009 19:17:11 -0800 schrieb Jeremy Chadwick <[email protected]>:
> On Sun, Feb 22, 2009 at 11:59:57AM +1100, Dmitri Nikulin wrote: > > On Sun, Feb 22, 2009 at 10:34 AM, Bill Hacker <[email protected]> > > 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
