Kai Krakow <hurikhan77@xxxxxxxxx> schrieb: > Chris Murphy <lists@xxxxxxxxxxxxxxxxx> schrieb: > >> On Tue, Mar 31, 2015 at 2:09 PM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> >> 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... BTW: I tried all kernels from current 3.19.x back to 3.18.0 which still live on my boot partition - each with the same result and very similar backtrace (SysRq+W)... -- Replies to list only preferred. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
