On Dec 9, 2013, at 11:54 AM, Niklas Schnelle <niklas.schnelle@xxxxxxxxx> wrote: > On Sat, Dec 7, 2013 at 11:30 PM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: >> >> On Dec 7, 2013, at 3:36 AM, Niklas Schnelle <niklas.schnelle@xxxxxxxxx> wrote: >> >>> Hi List, >>> >>> so first the basics. I'm running Arch Linux with 3.13-rc2, btrfs-progs >>> 0.20rc1.3-2 from the repo and I'm using a SSD. >> >> I don't see a dmesg, which should contain some information if there are correct or uncorrected problems at mount time. >> >> The first thing to try is the mount time recovery option. It's interesting considering how to do this for rootfs on btrfs, but I think simplest is to just add it to fstab and reboot. Then remove it. Again, check dmesg to see how the recovery went, and then check to see if you have the same problems. >> >> Another way to do it is to change the kernel parameters editing the e.g. GRUB menu entry at boot time. Change the ro to rw, and add recovery to rootflags=. So if the current one is rootflags=subvol=root, then change to rootflags=recovery,subvol=root. This acts as a one time thing. >> >> Ideally I'd like to see the kernel spit out something systemd could use that would cause it to generate a service to remount using recovery (and if multiple devices, possibly degraded, and if either of those fail, to then generate a remount service for ro,recovery and fallback to emergency.target). That way more of this can be done automagically. >> >> So try the recovery mount option first. Before you try btrfs check (or btrfsck), you should upgrade your btrfs-progs to something more recent. v3.12 is current and is what distros should build as of kernel 3.12. > As it says in the threads subject there were no errors in dmesg. I > tried the recovery mount option now but also > got no notable output in dmesg. Any idea how to procede? By the since > I was able to delete the undeleteable directory > after running btrfs check --repair (freshly compiled git version) my > filesystem has shown no odd behavior, though > obviously I'm not really trusting it as there were errors in btrfs > check when running it again after the repair. Since you've made some changes, I think we need an update on what errors you're still receiving. I'm a bit baffled that mounting rw,recovery shows nothing in dmesg, yet you get errors with btrfs check. Maybe someone else has some ideas how to get more info. Maybe add kernel parameters 'debug ignore_loglevel' ? Chris Murphy-- 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
