On Thu, Oct 11, 2012 at 07:26:28AM -0400, Chris Mason wrote: > 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 ;)
Any luck on this? It's still happening in the latest kernels. If there's anything / patch you want me to try, let me know. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- 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
