Export did not go very well.
j...@opensolaris:~# zpool export master
internal error: Invalid argument
Abort (core dumped)
So I deleted (renamed) the zpool.cache and rebooted.
After reboot I imported the pool and it seems to have gone well. It is now
scrubbing.
Thanks a lot for the help!
j...@
Thanks! I will try later today and report back the result.
--
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
On Oct 28, 2010, at 04:44, Jan Hellevik wrote:
So, my best action would be to delete the zpool.cache and then do a
zpool import?
Should I try to match disks with cables as it was previously
connected before I do the import? Will that make any difference?
BTW, ZFS version is 22.
I'd say
I think the 'corruption' is caused by the shuffling and mismatch of the disks.
One 1.5TB is now believed to be part of a mirror with a 2TB, a 1TB part of a
mirror with a 1.5TB and so on. It would be better if zfs would try to find the
second disk of each mirror instead of relying on what control
On Wed, October 27, 2010 15:07, Roy Sigurd Karlsbakk wrote:
> - Original Message -
>> Ok, so I did it again... I moved my disks around without doing export
>> first.
>> I promise - after this I will always export before messing with the
>> disks. :-)
>>
>> Anyway - the problem. I decided to
- Original Message -
> Ok, so I did it again... I moved my disks around without doing export
> first.
> I promise - after this I will always export before messing with the
> disks. :-)
>
> Anyway - the problem. I decided to rearrange the disks due to cable
> lengths and case layout. I disc
Ok, so I did it again... I moved my disks around without doing export first.
I promise - after this I will always export before messing with the disks. :-)
Anyway - the problem. I decided to rearrange the disks due to cable lengths and
case layout. I disconnected the disks and moved them around.
