On Sat, Apr 2, 2016 at 10:02 PM, Kai Krakow <hurikhan77@xxxxxxxxx> wrote: > Am Sat, 2 Apr 2016 18:14:17 -0600 > Also I think, having options nossd+autodefrag+lzo shouldn't be an > exotic or unsupported option. Having this on top of bcache should just > work. I'm not suggesting it shouldn't work. But in fact something isn't working. Bugs happen. Regressions happen. This is a process of elimination project to find out either why, or under what condition(s), it doesn't work. > Does it make sense while I still have the corruptions in the FS? I'd > like to wait for Qu whether I should recreate the FS or whether I > should take some image, or send info to improve btrfsck... It's up to you. I think it's fair to say the file system should not be corrupting files so long as it's willing to write to the volume. So that's a problem in and of itself; it should sooner go read only. It's completely reasonable to take a btrfs-image, back everything up, and then try a 'btrfs check --repair' and see if it can fix things up. If not, that makes the btrfs-image more valuable. > I think the latter two are easily the least probable sort of bugs. But > I'll give it a try. For the time being, I could switch bcache to > write-around mode - so it could at least not corrupt btrfs during > writes. I don't know enough about bcache to speculate what can happen if there are already fs corruptions. Is it possible bcache makes things worse? No idea. -- Chris Murphy -- 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
