On Wed, Feb 17, 2010 at 23:21, Bob Friesenhahn <bfrie...@simple.dallas.tx.us > wrote:
> On Wed, 17 Feb 2010, Ethan wrote: > >> >> I should have a partition table, for one thing, I suppose. The partition >> table is EFI GUID Partition >> Table, looking at the relevant documentation. So, I'll need to somehow >> shift my zfs data down by 17408 >> bytes (34 512-byte LBA's, the size of the GPT's stuff at the beginning of >> the disk) - perhaps just by >> >> Does that sound correct / sensible? Am I missing or mistaking anything? >> > > It seems to me that you could also use the approach of 'zpool replace' for > each device in turn until all of the devices are re-written to normal > Solaris/zfs defaults. This would also allows you to expand the partition > size a bit for a larger pool. > > Bob > -- > Bob Friesenhahn > bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ > GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ That is true. It seems like it then have to rebuild from parity for every drive, though, which I think would take rather a long while, wouldn't it? I could put in a new drive to overwrite. Then the replace command would just copy from the old drive rather than rebuilding from parity (I think? that seems like the sensible thing for it to do, anyway.) But I don't have a spare drive for this - I have the original drives that still contain the truecrypt volumes, but I am disinclined to start overwriting these, this episode having given me a healthy paranoia about having good backups. I guess this question just comes down to weighing whether rebuilding each from parity or re-copying from the truecrypt volumes to a different offset is more of a hassle. -Ethan
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss