Swâmi Petaramesh posted on Tue, 25 Aug 2015 10:18:26 +0200 as excerpted: > Le vendredi 21 août 2015 11:23:19 Duncan a écrit : >> So I'd suggest running btrfs check, without --repair, first, and see >> what it says. If the only reported problems have to do with inode >> refcounts, then (assuming your backups are current, just in case, >> admin's rule of backups, if you don't have them, you don't care about >> losing the data) I'd then go ahead and run it with --repair. > > Hi Duncan, > > Here's what I get using "btrfs check" on said device. Do you think that > running it with "--repair" would be beneficial, or risky ? > > root@partedmagic:~# btrfs check /dev/VGZ/LINUX > Checking filesystem on /dev/VGZ/LINUX > UUID: 13c87f57-3a85-4daf-a4bf-ba777407c169 > checking extents > checking free space cache > checking fs roots > root 267 inode 297 errors 200, dir isize wrong > root 267 inode 3341 errors 200, dir isize wrong > root 267 inode 324547 errors 200, dir isize wrong [and many more errors 200, dir isize wrong, errors flagged, with no other errors listed] While cautioning that I'm not a dev, just a btrfs user and list regular... and I haven't had that particular problem and thus no directly apropos personal experience here... The errors 200 flags are reasonably common, and I believe btrfs check --repair handles them well. I already stressed the admin rule that no backups means you don't care if it's lost, so with that in mind, I'd say go ahead with the --repair... as, based on the information I have, I would were I to see that here. -- 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
