Errors on a file on a zpool: How to remove?

[jhell]

On Sat, 23 Jan 2010 23:17, rincebrain@ wrote:
>> Can you try the following please and then report back.
>>
>> Setting failmode to continue might let you continue a removal.
>> zpool set failmode=continue what_is_it_rigatoni?
>>
>> This should be inherited by effected drives.
>> zfs set checksum=off what_is_it_rigatoni?
>>
>> Remove the said effected files at this point.
>
> [root at manticore ~]# zpool set failmode=continue rigatoni
> [root at manticore ~]# zfs set checksum=off rigatoni
> [root at manticore ~]# mv
> /mirrors/geocities/from-asheesh-home/swebb3/www.geocities.com/JMcgo1979
> /mirrors/geocities/from-asheesh-home/swebb3/www.geocities.com/JMcgo19791
> mv: rename /mirrors/geocities/from-asheesh-home/swebb3/www.geocities.com/JMcgo1979
> to /mirrors/geocities/from-asheesh-home/swebb3/www.geocities.com/JMcgo19791:
> Input/output error
> [root at manticore ~]# rm -f
> /mirrors/geocities/from-asheesh-home/swebb3/www.geocities.com/JMcgo1979
> rm: /mirrors/geocities/from-asheesh-home/swebb3/www.geocities.com/JMcgo1979:
> Input/output error
>
> :/
>
> - Rich
>

I had my fingers crossed for you to... :(

>From what I see and what was already mentioned earlier in this thread is 
meta data corruption but the checksum errors do not span across the whole 
pool of vdevs. These are, correct me if I am wrong USB mass storage 
devices ? SSD ?

In the arrangement of the devices on the system are da2,4,5 on the same hub 
and da6,7 on another ? If this is the case you may have consolidated your 
errors down to being a USB problem and narrowed down to where they are 
connected to.

What happened to da1,3 ? Were these once connected to the system ? and if 
so did you start noticing this problem occur roughly about the same period 
they were removed ?

Will zpool(8) allow a removal of a vdevs in operation and copy the data 
to the leftover vdevs if there is free space ?

As in: (maybe possibly with -f)

zpool remove da2
zpool remove da4
zpool remove da5

Maybe if it is a possibility, replace each with another daN device if one 
is available and continue operations from this point to see if you can 
most likely rm the files in question as they are unlikely to be 
recoverable.

Fingers crossed,

-- 

  jhell