Hi, > The ZFS way is a nice way to do this, except I'd need > to keep a set of blank images around and local disk > space is of a premium on a mirrored blade :-( ** > Second thoughts I could probably use a compressed > volume for this, but I'm not sure if the clone would > give me another compressed filesystem, take a while > to uncompress or just simply work. **
A clone of a compressed filesystem should "just work" and the clone command would not have to decompress the snapshot being cloned. But, I don't follow why you would need to keep blank images around. A clone takes up no additional space until it is modified or the cloned filesystem is modified. Along the lines of thin provisioning, what you can also do is to create a ZFS sparse volume (zfs create -s -V) of arbitrary size and use that as your root disk. This works just like a normal ZFS filesystem in that you can snapshot and clone it. Alex's comment applies here in that you may run out of space in your zpool when the domain still sees a large disk with available space. Although, using ZFS, you can always add more storage to your pool. Support for this is in OpenSolaris and s10u5. This definitely hasn't been tested as much as mkfile on ZFS filesystems though. > In my current setup each LDom is getting it's own ZFS > filesystem for it's boot disk and uses a shared ZFS > filesystem for swap. That way I can stop an LDom, > create a snapshot and roll forwards/back at a later > stage as needed. Do you mean that you have more than one LDom using the same swap space? Haik -- This message was posted from opensolaris.org
