2012-05-03 9:44, Jordi Espasa Clofent wrote:
> Note, as you can see, the slice 0 i used for 'rpool' and the slice 7
> is used for 'opt'. The autoexpand propierty is enabled in 'rpool' but
> is disabled in 'opt'
> This machine is a virtual one (VMware), so I can enlarge the disk
> easily if I need. Let's say I enlarge the disk 10 GB:
> PS. I know perfectly how to expand any zpool just adding a new device;
> actually I think is even better, but that's not the point.
The rpool has some limitations compared to other pools; for example,
it can not be concatenated or striped from several locations. Each
component of the rpool (single device or part of the mirror) must be
self-sufficient in case of catastrophic boots.
So adding a new device to rpool won't help.
As for autoexpansion, it works "in-place" - if the device which
contains the pool becomes larger, the pool can increase. In case
of rpool, the device is c0t0d0s0 slice. After you increase the
disk, you should also use tools like format, fdisk and/or parted
to increase the Solaris partition (in external MBR-table layout),
then you should relocate the "opt" pool's sectors towards end of
disk while that pool is exported and not active, then relabel
the Solaris slices with format so as to change the s7's "address"
and expand the s0 slice. Then the singular device of rpool would
become bigger and it should autoexpand.
The tricky part is relocation of opt. I think you can do this
with a series of dd invokations going with chunks of say 1Gb,
starting from the end of its slice (end-1Gb), because by the
time you're done, 2/3 of original opt slice would be overwritten
by its own relocated data.
It would likely be more simple and safe to just back up the data
from your nearly empty opt pool (i.e. zfs send | zfs recv its
datasets into rpool), destroy opt, relabel the solaris slices
with format, expand rpool, create a new opt. You should back it
up anyway before such dangerous experiments
But for the sheer excitement of the experiment, you can give
the dd-series a try, and tell us how it goes
zfs-discuss mailing list