The way I understood this line in dmesg: "BTRFS info (device sdc1): The free space cache file (2159324168192) is invalid. skip it" was: "here's some info. There was a file caching some work, but the cache turned out to be invalid, so we won't be using it. We'll do the work that it was caching, instead. This is not an error, it's just for your information. If it were an error we would have told you." On Mon, Jan 11, 2016 at 10:03 AM, Hugo Mills <hugo@xxxxxxxxxxxxx> wrote: > On Sun, Jan 10, 2016 at 05:13:28PM -0700, Chris Murphy wrote: >> On Sat, Jan 9, 2016 at 2:04 PM, Hugo Mills <hugo@xxxxxxxxxxxxx> wrote: >> > On Sat, Jan 09, 2016 at 09:59:29PM +0100, cheater00 . wrote: >> >> OK. How do we track down that bug and get it fixed? >> > >> > I have no idea. I'm not a btrfs dev, I'm afraid. >> > >> > It's been around for a number of years. None of the devs has, I >> > think, had the time to look at it. When Josef was still (publicly) >> > active, he had it second on his list of bugs to look at for many >> > months -- but it always got trumped by some new bug that could cause >> > data loss. >> >> >> Interesting. I did not know of this bug. It's pretty rare. > > Not really. It shows up maybe on average once a week on IRC. It > gets reported much less on the mailing list. > > Hugo. > > -- > Hugo Mills | What part of "gestalt" don't you understand? > hugo@... carfax.org.uk | > http://carfax.org.uk/ | > PGP: E2AB1DE4 | -- 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
