See bottom, my filesystem mounts, but apparently it's still corrupted as per btrfs-image output
On Tue, Jan 08, 2013 at 05:10:12PM +0000, Hugo Mills wrote: > > Question #1: > > I have hourly snapshots of my root filesystem, and I wasn't able to mount > > any of them. I got the BUG at fs/btrfs/volumes.c:3707 each time. > > gandalfthegreat:~# mount -o ro,recovery /dev/mapper/root -o > > 'subvol=root_daily_20130108_00:01:02,defaults,compress=lzo,discard,nossd,space_cache,noatime' > > > > If my log is damaged, why are all other snapshots also broken? > > Snapshots are not independent of each other. The filesystem as a > whole is damaged -- if you can't mount it, it won't make a difference > which subvolume you try to mount. A snapshot is not a backup; it won't > save you from a broken filesystem or dead hardware. At best, it'll > save you from accidental deletion of files. Thanks for explaining. I guess it makes sense that the log is not a per subvolume thing, but a filesystem-wide thing. Last time I posted this problem, someone replied and suggested that I tried mounting an older snapshot, but now I understand that it won't help. > Oopses in log playback are a bug. The last time we had such a bug > which was identifiable and traceable (back in the 3.1-3.2 era, IIRC), > it got fixed, eventually. So yes, this is a bug, it should be fixed, > and you're not the only person to have seen log tree replys fail in > 3.6 and 3.7 kernels. > Since you seem to be hitting the problem frequently and repeatably, > could you help? Josef has said he'd like a copy of the filesystem > image that btrfs-image produces when run against the broken FS (i.e. > while the FS can't mount) -- that would help track down the corruption > problem, and make the kernel more robust in this area. Just as a > warning, the output may be quite large: it contains all of your FS's > metadata. Argh, I reported this here with 3.6.3 3 months ago and waited an entire week for someone to tell me what they wanted off my FS before I removed all evidence of the bug, but never got a reply asking for anything. Since I didn't read any updates since then or found anything new on https://btrfs.wiki.kernel.org/index.php/Problem_FAQ#I_can.27t_mount_my_filesystem.2C_and_I_get_a_kernel_oops.21 I just went ahead and fixed my laptop right away this morning, sorry about that. Because it's my main work laptop, I don't want to break it on purpose, or risk corruption that I may not notice and would creep in my incremental backups, so I'd rather not try and reproduce this on purpose, but if you want a way to reproduce this, I think pulling the sata cable off a drive while writing a few times should reproduce this pretty easily (or maybe even just pulling power although I know pulling power still lets some drives write some things before they shut down) I'm however likely to hit the problem again sooner or later, whether I want it or not. I'll make sure to run btrfs-image next time. Ok, how about this. 1) I updated https://btrfs.wiki.kernel.org/index.php/Problem_FAQ to tell people to run btrfs-image. It'll be easier for you to get what you need if it's documented somewhere :) Please update it further to say what people should do since posting on the list does not always yield timely replies for people who need to recover soon-ish from backup if necessary. 2) You may still be in luck, maybe? and me not so much. I thought my filesystem was recovered, I'm running it right now, but: gandalfthegreat:~# btrfs-image -c 9 -t 8 /dev/mapper/cryptroot /var/tmp/fs_image Check tree block failed, want=5212229632, have=12481778023482407252 Check tree block failed, want=5212229632, have=12481778023482407252 Check tree block failed, want=5212229632, have=14440972074482314957 Check tree block failed, want=5212229632, have=12481778023482407252 Check tree block failed, want=5212229632, have=12481778023482407252 read block failed check_tree_block btrfs-image: btrfs-image.c:518: create_metadump: Assertion `!(ret < 0)' failed. Aborted gandalfthegreat:~# l /var/tmp/fs_image -rw-r--r-- 1 root root 234413056 Jan 8 09:58 /var/tmp/fs_image No idea what version I have because it won't say: gandalfthegreat:~# btrfs-image --version btrfs-image: invalid option -- '-' usage: btrfs-image [options] source target -r restore metadump image -c value compression level (0 ~ 9) -t value number of threads (1 ~ 32) gandalfthegreat:~# btrfs-image -v btrfs-image: invalid option -- 'v' (...) Is my incomplete /var/tmp/fs_image useful, or anything else you want out of my maybe still corrupted filesystem? Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/
signature.asc
Description: Digital signature
