On Thu, Oct 11, 2012 at 01:28:21AM -0600, Richard W.M. Jones wrote: > Well the bad news is that the bug happened again overnight, even > though we were definitely using btrfs-progs with the 6eba90029 patch > added, _and_ it was doing a sync + fsync between the mkfs and the > mount.
This is good just because it makes the most sense. The only thing worse than a bug is a bug that disappears for the wrong reasons ;) > > Here is the log: > [ 17.943272] btrfs bad tree block start 0 135168 > [ 17.955270] btrfs: open_ctree failed This is also good because it really points to the invalidate. You've got zeros where we wrote 135168, and pretty much the only way to get zeros on a disk block is if the kernel did a memset. Sure some app could have written the zeros there, but that block offset is unlikely to get allocated as a data block by the other filesystems. So, I'll go back to the invalidate code ;) -chris -- 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
