David, no ultimate answers but some ideas. I've just had comparable issues on a mirror with all the maintenance tools not working as expected. I my case the problem came down to 1- a bad power cable to one of the disks loosing contact once in a while, 2- a non-locking SATA cable that came out ever so little from the socket. Luckily both were focussed on the same physical drive.
My BIOS mostly showed both disks. Only once one drive was missing leading to the power supply. 'format' always (!) showed both disks of the mirror. You ask about the effect of the commands logical vs. physical. My understanding is that they are simply tools for the handling of how the OS sees the drives. So a logical level within the pools. 'zpool replace' (see 'man zpool') allows you to logically replace the drive in the pool. As it carries out the resilvering, both, the old and new physical disk have to be present in the system. At least that is how I understand the 'replace' option. >From the man pages: zpool replace [-f] pool old_device [new_device] replaces old_device with new_device. This is equivalent to attaching new_device, waiting for it to resilver, and then detaching old_device Since you should not remove physical devices from a zpool without telling the OS something about it you need to use 'zpool detach' (or similar). Trying to attach my badly connected drive led the 'zpool attach mypool drive' command to tell me about using fdisk and slices. Rather misleading, maybe like what you are seeing. Regarding the extra space used. I just posted a similar question: http://www.opensolaris.org/jive/thread.jspa?threadID=114104&tstart=0 Though I have no idea how that fits to the initial problem, if at all, never mind where that data is... Maybe you could post your 'df -h' and 'zfs list' output? Hope this helps a bit, Martin -- This message posted from opensolaris.org
