Marc MERLIN posted on Tue, 05 May 2015 14:02:09 -0700 as excerpted: > Please let me know what I can do for you if anything, before I wipe the > filesystem and recreate it (I'm assuming that running btrfs check > --repair a 2nd time won't help). FWIW... I had a second /similar/ case here, but I didn't report it, as I thought it related to a relocated-sector count bump I saw on one of the ssds at about the same time. My case may well have indeed been relocated- sector-triggered, but reading your case, it's similar enough that I thought I'd mention it. Like you I noticed a problem that didn't seem to have too much real-world effect, in my case, simply an apparently empty directory that would trigger a "directory not empty" error on attempt to delete. Having read about others having such problems, I immediately used their solution, simply rename the directory out of the way, for the time being, after which it didn't seem to cause any harm, just annoyance as I still couldn't delete it. But, with scrub fixing a couple corruptions and further scrubs finding nothing more, yet I still couldn't delete the dir, again like you, I decided to try a btrfs check, first read-only, which reported a few problems (which I didn't save), then with --repair, which /seemed/ to work just fine. And finally, like you, a few hours later, actually in my case after a shutdown and reboot with successful error-free remount... suddenly that filesystem went read-only! That's the end of the similarities, but as you can see, they're striking enough to think it might be the same issue (1) relatively minor initial problem, (2) btrfs check --repair apparently fixes it, (3) a few hours later the filesystem goes read-only, and immediate efforts to fix it fail. What follows is how I recovered... Well, I have my system on multiple independent btrfs for a reason, and that was /home, with / a totally independent btrfs mounted read-only by default, and mounted read-only at the time. So I quit X and logged out of my normal user, logged in as root at the CLI, did a systemctl emergency to stop all normal services, and a umount -a to unmount all filesystems that could unmount. Then I went to work trying to fix the bad btrfs, still running from the unaffected read-only /, of course. Long story short, nothing I tried (mounting with recovery, the new integrated btrfs rescue zero-log, btrfs check --repair...) seemed to fix it. =:^( So I got to use the new btrfs-progs v4.0 metadata-restoration option in btrfs restore, updating my previous btrfs restore experience from nearly a year ago. =:^) The good news: btrfs restore worked without having to do the manual find- root thing, and the metadata-restore options are very nice indeed! I seem to have gotten my files back, and didn't have to resort to my backup (which was out of date, but I'd have used it and been happy if I had to, I just didn't have to). =:^) The bad news: restore's dry-run option doesn't work well with metadata- restore, giving metadata unavailable errors on the dry-run that aren't there on an actual write-it-out restore. Also, the old too many loops on the same dir warning and abort, no longer affects a write-out run, but still affects a dry-run. So the dry-run provides /some/ idea what you'll get, but it's not really an accurate literal dry-run, going thru all the motions but effectively /dev/nulling the output. =:^( Also, I guess the symlink restore patch didn't make it in time for progs 4.0. Hopefully for 4.0.1 or at least 4.1... So my symlinks weren't restored and I still had to recreate them manually. But the experience was markedly better than last year, since I didn't have to: (1) rerun restore repeatedly until I no longer got the looping errors, (2) manually fix ownership/perms. -- 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
