Everyone knows what raid0 entails. Moreover, with btrfs being an experimental fs, not having backups would obviously be pure idiocy. I wrote that it was "pretty serious" because the situation came out of nowhere on a low-traffic fs on which the most exiciting thing that can happen is an occasional snapshot once on a while when I do a heavy update with apt-get (snapshot that gets always removed right after the update goes invariably well and my paranoia fades). The problem seems to have happen right after a hard lock probably due to 3.17.0-rc3 (and before you explain to me what that rc3 stands for, let me tell you that I'm not complaining, I knew what I was doing). I had to power-off "brutally" and right after that the problem occurred. I'm pretty sure about that because for obvious reasons I rsync the hell out of that filesystem every chance I get. Rsync obviously does a traversal of the fs and so the "critical" (btrfs words, not mine) problem would have showed on kmsg (another place that I watch like a hawk, because of the raid0+experimental fs thing). I don't know if you are a btrfs developer but that "pretty serious" was not meant to offend them nor to complain. Actually I've been a pretty happy customer up until now (and I still am) because I have never been bitten by any big bug even with such a complex fs. I just have this zombie directory that can't be rm'd, but I mv'd out of the way and everything is fine. It'll get sorted when I do the next wipe-and-restore iteration (again, being experimental, I don't let the fs to become too "old"). So, the "pretty serious" was more due to the surprise than anything else. John -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
