Am Sat, 26 Mar 2016 14:28:22 -0600 schrieb Chris Murphy <li...@colorremedies.com>:
> On Sat, Mar 26, 2016 at 1:30 PM, Kai Krakow <hurikha...@gmail.com> > wrote: > > > Well, this time it hit me on the USB backup drive which uses no > > bcache and no other fancy options except compress-force=zlib. > > Apparently, I've only got a (real) screenshot which I'm going to > > link here: > > > > https://www.dropbox.com/s/9qbc7np23y8lrii/IMG_20160326_200033.jpg?dl=0 > > This is a curious screen shot. It's a dracut pre-mount shell, so > nothing should be mounted yet. And btrfs check only works on an > unmounted file system. And yet the bottom part of the trace shows a > Btrfs volume being made read only, as if it was mounted read write and > is still mounted. Huh? It's a pre-mount shell because I wanted to check the rootfs from there. I mounted it once (and unmounted) before checking (that's bcache{0,1,2}). Yeah, you can get there forcibly by using rd.break=pre-mount - and yeah, nothing "should" be mounted unless I did so previously. But I cut that away as it contained unrelated errors to this problem and would be even more confusing. The file system that failed then was the one I just mounted to put the stdout of btrfsck on (sde1). That one showed these (screenshot) kernel console logs just in the middle of typing the command - so a few seconds after mounting. What may be consusing to you: I use more than one btrfs. ;-) bcache{0,1,2} = my rootfs (plus subvolumes) sde = my USB3 backup drive (or whatever the kernel assigns) Both run btrfs. The bcache*'s have their own problems currently, I'd like to set those aside first and get the backup drive back in good shape. The latter seems easier to fix. -- Regards, Kai 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
