Sorry for the delay of my reply...

This small mail to let you know that my RAID array is currently recovering 
thanks to the valuable inputs of this mailing list users. You are great!

For the curious, what I did is the following:

# ##### Do not forget the '--assume-clean' as I almost did! ;-(
# mdadm -C /dev/md2 -l 10 -n 4 -c 64 -e 0.90 --assume-clean /dev/sdd1 missing 
/dev/sdc1 missing               
# vgchange -a y                                                                                               
# xfs_repair -n -t 1 -v /dev/my-vg/my-lv
# mount -o ro /dev/my-vg/my-lv /mnt/tmp
# find /mnt/tmp
# du -ks /mnt/tmp/
# umount /mnt/tmp
# #### Required: XFS asked the log to get replayed
# mount /dev/my-vg/my-lv /mnt/tmp/
# umount /mnt/tmp
# xfs_repair  -t 1 -v /dev/my-vg/my-lv
# mdadm --manage /dev/md2 --add /dev/sde1
# mdadm --manage /dev/md2 --add /dev/sdf1

The array is currently at 25 % of the recovery process. A bit too soon to say 
that everything is fine... By the way, I am quite sure now that my USB 
controllers (or the use driver or whatever in the chain except all disks) are 
buggy: all the other RAIDs of my setup are gone!

I will try to recover them using the same kind of process, to backup all data. 
Do you think that using BBR (since each time, the burden started due to a 
sector (write?) error), the problem will be "solved" (or at least postponed 
until BBR itself does not have enough free sectors)?

Anyway, again, thanks a lot to all of you. 
Open Source rocks! ;-)
-- 
Pierre Vignéras
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html