Chris Murphy <li...@colorremedies.com> schrieb: > On Tue, Mar 31, 2015 at 2:09 PM, Chris Murphy <li...@colorremedies.com> > wrote: > >> Well you have to rule that out before anyone on this list can really >> help. Try booting Fedora 21 install media, and using smartctl -x on >> the drive. > > While you're at it, try to mount the Btrfs volume in question normally > and report kernel messages. If mount fails, try it with -o recovery > mount option, and also report kernel messages and whether that fails.
I had this happen, too, lately. It's quite often happening after an unclean shutdown (which currently quite often happend to me due to the xorg intel driver having GPU freezes). SysRq+W shows that the mount process is locked somewhere in the btrfs code path and won't quit if Ctrl+C'd... Only way to fix it was to btrfs-zero-log. But it still took some reboots from initramfs until it successfully mounted again (I could mount it in initramfs right after zero-log but upon reboot it hung again though at a different stage probably). So I guess there's some race on the one hand (happens from time to time non- related to fixing it with zero-log), and a deadlock on the other hand after some unclean shutdowns (more or less random). My setup is 3-device btrfs-mraid1-draid0 on bcache. Bcache wasn't involved in the backtrace of SysRq+W, however. Apparently I don't have a screenshot of it because my smart phone is currently fried... -- Replies to list only preferred. -- 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
