On 8/9/07, Mario Goebbels <[EMAIL PROTECTED]> wrote: > If you're that bent on having maximum redundancy, I think you should > consider implementing real redundancy. I'm also biting the bullet and > going mirrors (cheaper than RAID-Z for home, less disks needed to start > with).
Currently I am, and as I'm stuck with different sized disks I first have to slice them up to similarly sized chunks and .. well you get the idea. It's a pain. > The problem here is that the filesystem, especially with a considerable > fill factor, can't guarantee the necessary allocation balance across the > vdevs (that is maintaining necessary free space) to spread the ditto > blocks as optimal as you'd like. Implementing the required code would > increase the overhead a lot. Not to mention that ZFS may have to defrag > on the fly more than not to make sure the ditto spread can be maintained > balanced. I Feel that for most purposes, this could be fixed with an allocator strategy option, like: Prefer vdevs with most free space (which is not that good a default as it has performance implications). > And then snapshots on top of that, which are supposed to be physically > and logically immovable (unless you execute commands affecting the pool, > like a vdev remove, I suppose), just increase the existing complexity, > where all that would have to be hammered into. I'm not that familiar with the code, but i get the feeling that if vdev remove is a given, rebalance would not be a huge step? The code to migrate data blocks would already be there. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
