Roman Mamedov posted on Fri, 04 Aug 2017 12:44:44 +0500 as excerpted: > On Fri, 4 Aug 2017 12:18:58 +0500 Roman Mamedov <rm@xxxxxxxxxxx> wrote: > >> What I find weird is why the expected csum is the same on all of these. >> Any idea what this might point to as the cause? >> >> What is 0x98f94189, is it not a csum of a block of zeroes by any >> chance? > > It does seem to be something of that sort, as it appears in > https://www.spinics.net/lists/linux-btrfs/msg67281.html (though as > factual csum, not the expected one). > >> a few files turned out to be unreadable > > Actually, turns out ALL of those are sqlite files(!) > > .mozilla/firefox/.../places.sqlite <- 4 instances (for 4 users) > .moonchild productions/pale moon/.../urlclassifier3.sqlite > .config/chromium/Default/Application Cache/Cache/data_3 <- twice (for 2 > users) > .config/chromium/Default/History .config/chromium/Default/Top Sites > > nothing else affected. > > Forgot to mention that the kernel version is 4.9.40. Not very scientific but FWIW... Kernel 4.9 or perhaps a couple kernel cycles earlier is about the time I had some similar issues with my firefox database files, too. I lost extensions and their settings and had to bisect to the file level and restore the files from backup. The problem in my case was very likely an ungraceful shutdown. But I've had a couple such shutdowns recently (I stay current and am now on 4.13- rc3) as well, due to summer storm season and a power supply going out, that have had much better results -- clean scrubs after remount and nothing lost that I can see, even after the one that blinked back out right as I was rebooting. So it may be something fixed in newer kernels or just happenstance, but I won't argue with more reliable recent kernel btrfs, even if it /is/ "just me". =:^) -- 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
