On 3/12/13 8:38 PM, Russell Coker wrote: > I have a workstation running the Debian packaged 3.7.1 kernel from 24th > December last year. After some period of uptime (maybe months) it crashed > and > mounted the root filesystem read-only. Now when I boot it the root > filesystem > gets mounted read-only. > > I have attached the dmesg output from the last boot. > > The system has an Intel 120G SSD and apart from 4G of swap and 400M of /boot > it's all a single encrypted BTRFS filesystem. > > Any suggestions on what I should do next?
Not offhand, but I took a look at the logs, and maybe this will help the people who are more guru-like than I am. First you hit: [ 37.175750] btrfs: corrupt leaf, bad key order: block=70852288512,root=1, slot=8 [ 37.176435] btrfs: corrupt leaf, bad key order: block=70852288512,root=1, slot=8 which led to an aborted transaction and an attempt at graceful shutdown: [ 37.176478] WARNING: at /build/buildd-linux_3.7.1-1~experimental.1-amd64-lU7Aeh/linux-3.7.1/fs/btrfs/super.c:246 __btrfs_abort_transaction+0x4c/0xcf [btrfs]() [ 37.176481] btrfs: Transaction aborted ... [ 37.176790] BTRFS error (device dm-0) in __btrfs_free_extent:5143: IO failure [ 37.176791] btrfs is forced readonly [ 37.176793] btrfs: run_one_delayed_ref returned -5 in the end, despite that attempt at graceful exit, you hit: [ 37.937174] kernel BUG at /build/buildd-linux_3.7.1-1~experimental.1-amd64-lU7Aeh/linux-3.7.1/fs/btrfs/transaction.c:1753! because in btrfs_clean_old_snapshots(), btrfs_drop_snapshot() failed, and BUG_ON(ret < 0); it doesn't handle that well. I have no idea what btrfsck might do, but it seems like if there is a corrupt leaf, that might be in order. I might make a device image first, as well. -Eric -- 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