On Sun, Dec 27, 2009 at 12:03 AM, Michael Disserman <[email protected]> wrote: >>Since it's domU, if all you need is increase the rpool disk size, > there's probably a much simpler method. Extend the disk backing store > (like by resising the zvol). The hard part then is adjusting the > partition and slice (which I haven't personally tried) so that zfs > will recognize the new disk size. > > that's one of the ways however I don't know how correctly extend the > partition and how to extend ZFS when the new partition table is set. There's > no any resizezfs like i.e. resize2fs in Linux.
Ah, OK, now we're getting somewhere :D What happens is that zfs (until now, I think) will simply use all available space. So it automatcially extends itself to occupy the available space after a boot or import. There's no need for a resize2fs-equivalent. The term "available space" can differ in meaning though. When used directly on top of a block device (like on top of LVM with zfs-fuse on Linux), if you extend that LV and do export-import of the pool, zfs will recognize the new size (this is what I usually do). Same thing goes with partition, if you put zfs on partiton, extend the partition (i.e. with parted or similar) and zfs will recognize the new size after the next export-import. In rpool, zfs uses slice. I don't now of any program that can safely extend a solaris slice, so you MIGHT be able to achieve a similar effect by writing down the old partition table and solaris vtoc, then creating a new one that reflects the new size. Note that I haven't tried this personally (never had the need to), but this was mentioned some time ago in this list. As I recall there were also plans to make zfs be able to recoginze the new size without export/import, and that the "automatic extend" feature should be tunable via a zpool property, but I haven't heard about it for some time, so most likely they still behave like what I mentioned above. -- Fajar _______________________________________________ xen-discuss mailing list [email protected]
