Michael Zugelder posted on Mon, 17 Jun 2013 21:10:27 +0200 as excerpted: > Hi, > > my laptop with a btrfs on dm-crypt on SSD freezed today shortly after > resuming from suspend (it doesn't normally do that). I was running a > self compiled 3.9.6 at this point. There should be around 20 of 114 GiB > free on the file system and it was probably created with 16K leaf size. > > After rebooting, mounting the rootfs didn't work anymore. I made a copy > of the disk and am now trying to fix it using my desktop. Trying to > mount it with -o recovery on 3.10-rc6 triggers the following bug: [snipped]
> Any suggestions? Never had a problem before running btrfs on that > machine and SSD for about 2 years now. The technical debugging's for others, but two suggestions as a btrfs user/ tester: 1) I had an similar issue some time back that turned out to be a corrupted space-cache. Try mounting with the "nospace_cache" option. If that works that's it; mount with the "clear_cache" option to clear the bad cache and perhaps once again with space_cache to turn it back on. (Space-cache is one of the few options that's persistent, but I'm not sure if no-cache is equally persistent, making it a toggle, or if once it's on there's no way to turn it off permanently.) The clear_cache option will trigger a cache rebuild, so will take some time on slower devices (you said SSD but didn't say whether it was a slow one or a fast one). See the mount-options page at the wiki for more. https://btrfs.wiki.kernel.org/index.php/Mount_options#Space_cache_control 2) Apparently some corruption bugs in 3.9 were fixed for 3.10. It's worth trying say the latest 3.10-rc kernel, to see if can handle it. As the wiki mentions in several places and as is frequently repeated here, btrfs is still under heavy development and the development kernels often have fixes missing in even latest stable. So unless there's a known regression in the current development kernel that you're purposefully avoiding, really, relatively speaking, in terms of btrfs development, latest mainline kernel stable is in practice already a bit dated, and btrfs testers are encouraged to run the development kernels from rc2 or rc3 at least. (I can understand not wanting to run them during the commit window, or until rc2/3, as I often hold off during the commit window here, too. Some even run btrfs-next, before it hits mainline, but I've chosen to stick with mainline here. That's just simpler all around for me, and the rcs are still current /enough/.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- 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
