Claus Guttesen wrote:
...
>>> Jul 25 13:15:00 malene arcmsr: [ID 419778 kern.notice] arcmsr0: scsi
>>> id=1 lun=3 ccb='0xff02e0ca0800' outstanding command timeout
>>> Jul 25 13:15:00 malene arcmsr: [ID 610198 kern.notice] arcmsr0: scsi
>>> id=1 lun=3 fatal error on target, device was gone
>> T
I had a drive fail in my home fileserver - I've replaced the drive,
but I can't make the system see it properly. I'm running nevada B85,
with 5 750GB drives in a raidz1 pool named "tank" and booting off a
separate 80 GB SATA drive I had laying around.
Without the new drive attached, I simpl
It looks like you *think* you are trying to add the new drive, when you are in
fact re-adding the old (failing) one. A new drive should never show up as
ONLINE in a pool with no action from your part, if only because it contains no
partition and no vdev label with the right pool GUID.
If I am r
Alan Burlison wrote:
> So how do I tell zfs receive to create the new filesystems in pool3, but
> not actually try to mount them?
This is even more of an issue with ZFS root - as far as I can tell it's
impossible to recursively back up all the filesystems in a root pool
because of this - the r
> - on a sun cluster, luns are seen on both nodes. Can
> we prevent mistakes like creating a pool on already
> assigned luns ? for example, veritas wants a "force"
> flag. With ZFS i can do :
> node1: zpool create X add lun1 lun2
> node2 : zpool create Y add lun1 lun2
> and then, results are unexpe
I have had the same problem too, but managed to work around it by setting the
mountpoint to none before performing the ZFS send. But that only works on
file-systems you can quiesce.
How about making a clone of your snapshot, then set the mounpoint of the clone
to none, take a snapshot of the u
