Suppose that you have a ZFS pool with various filesystems, and whilethe filesystems have data in them, you're just using the pool as acontainer; the top level pool filesystem has no data itself. In thissituation, a df of the pool on the Solaris host will show somethinglike:

Filesystem  size  used  availtank01      300G   20K    40G

Translated, we can see that the pool itself is 300G, the pool's toplevel filesystem has nothing

The easiest way to dig yourself out of the hole created by the RAIDgrowth gotcha is probably to use a live/rescue CD.But let us suppose that you don't have one handy, which was the casefor me yesterday. Further let us suppose that you have /boot as a separate filesystem , not as part of the rootfilesystem (if this is not the case, you absolutely need a rescue CD;sorry).

The basic goal is to rebuild a version of your current initrd that has

Suppose that you have a system with a mirrored root filesystem and,for some reason , you need to boot it withoutthe mirror being available. At one level, this is very easy; all youneed to do is to find the partition of one of the mirrors and specifyit as the filesystem root device on the kernel command line with' root=/dev/sdXX '.

This works because while software RAID embeds its own metadata in thepartitions, it puts the metadata at the end of the partition,

Suppose that you have a fully mirrored system and you want to expandyour available space by migrating to a pair of larger hard drives. Theobvious way to do this is fairly straightforward, assuming that youcan connect all of your drives at once: partition the new drives (withlarger partitions for at least some of your software RAID devices), addthe new partitions to the appropriate MD device, let things resync, andthen detach the old disks (and eventually physically remove them).

(Hopefully the obvious way