On 06/28/11 20:33, Alexander Motin wrote:
On 28.06.2011 18:09, O. Hartmann wrote:
Several maintenance of a ZFS pools has to be done and my intention was
to swap the 2TB hd disk (WDC WD20EARS-00MVWB0) with a 3TB hd disk
(WD30EZRX).
zfs umount works well,
zpool export POOL also worked well,
but I didn't find any "detach command" within camcontrol (I use the new
AHACI/CAM layout in the kernel on FreeBSD 9.0-CURRENT/amd64 r223597, so
my harddrives all show up as ada0 to ada4.
Since the box has a IcyDock 5-Slot backplane attached to the ICH0R
chipset and camcontrol doesn't reveal any detach command like atacontrol
did, I trusted in hotplugging capabilities and simply pulled the disk.
All right, the box reported a lost device but did not crash. The I
inserted the new drive. Entered
camcontrol rescan all
and
camcontrol devlist showed up the new device. But I can't do anything
with the drive. Even with the former device inserted again, rescaned
etc., a zpool import command get stuck as well as any diskinfo -ctv ada4
issued to the device. The drive shows up in camcontrol devlist, but
seems inoperable. What I'm doing wrong?
With controller in AHCI mode device plug-in should be detected without
any additional activity. If not, `camcontrol reset X`, `camcontrol
rescan X` sequence should force it, where X is a CAM scbus number.
Without additional info I can't say what went wrong there. I would
recommend to enable verbose kernel messages to get more info. Also
consider that SATA default timeout is 30 seconds, so if due to some
issues during plug-in some command was lost, recovery may take a bit.
I issued this command sequence (reset X, rescan X or rescan all), but
nothing happened.
When unpluggin the drive, I get a message from kernel, like "ada4 lost"
or similar, I don;t have the message handy right now (will provide
more). Plugging in the drive again, or even another hard drive, forces a
message from kernel on console reporting a device, like one will see
when kernel boots and drive gets detected.
A camcontrol rescan all and devlist shows also the new device.
But any kind of access to the new device, like gpart or simply a zpool
import to show the pool to be imported gets locked up forever (waited
two hours). The state could only be resolved by resetting the box and
then the filesystem is unclean an needs to be fsck'ed.
Will proceed with a verbose kernel.
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"