Hi, as I don't have much time to handle a long backup recovery, I didn't try the delete/add combination to avoid any risk. What I tried though, was fatal_errors=bug. As I don't have any console I thought it might at least help log the problem instead of the usual kernel panic.
No luck : the problem still made the kernel panic. Unless someone comes up with a somewhat safe way to recover from this situation I'll let the filesystem as is (we are building a new platform where redundancy will be handled by Ceph anyway). Lionel Le 27/10/2016 à 18:07, Lionel Bouton a écrit : > Hi, > > Le 27/10/2016 à 02:50, Lionel Bouton a écrit : >> [...] >> I'll stop for tonight and see what happens during the day. I'd like to >> try a device add / delete next but I'm worried I could end up with a >> completely unusable filesystem if the device delete hits the same >> problem than replace. >> If the replace resuming on mount crashes the system I can cancel it but >> there's no way to do so with a device delete. Or is by any chance the >> skip_balance mount option a way to cancel a delete ? > Can anyone just confirm (or infirm) that skip_balance will indeed > effectively cancel a device delete before I try something that could > force me to resort to backups ? > Lionel > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
