I don't know who else uses google-chrome here, but for me, for as long as I've used btrfs (3+ years now), I've had no end of troubles recovering from a linux crash, and google-chrome has had problems recovering my tabs and usually cmoplains about plenty of problems, some are corruption looking.
The way I recover, every time, is to simply rsync over the previous snapshot's data for ~/.config/google-chrome-dir back over the current corrupted one, and move on. I had a bit more look at this with a chrome engineer, and there seems to be at least a clear problem with leveldb where its file containing the index name, does not match the files on disk. Details are in https://bugs.chromium.org/p/chromium/issues/detail?id=738961 but I'll summarize here. All the files are in a non corrupted state, but I end up with this: saruman:~/.config/google-chrome-dir/google-chrome-beta/Default/IndexedDB/https_docs.google.com_0.indexeddb.leveldb$ l (...) -rw------- 1 merlin merlin 16 Oct 4 2016 CURRENT -rw------- 1 merlin merlin 0 Apr 9 2016 LOCK -rw------- 1 merlin merlin 0 Jul 5 22:31 LOG -rw------- 1 merlin merlin 0 Jul 5 22:31 LOG.old -rw------- 1 merlin merlin 23 Jul 3 08:31 MANIFEST-000001 -rw------- 1 merlin merlin 8639 May 12 17:36 MANIFEST-022745 saruman:~/.config/google-chrome-dir/google-chrome-beta/Default/IndexedDB/https_docs.google.com_0.indexeddb.leveldb$ cat CURRENT MANIFEST-010814 In other words, I think things go like this: - MANIFEST-010814 is replaced by MANIFEST-022745, - MANIFEST-022745 is written into the file CURRENT - ideally both MANIFEST-010814 and MANIFEST-022745 should be present on disk and MANIFEST-010814 deleted only after CURRENT has been written to with the new pointer, but I'm not sure if or how that is done. - my laptop crashes - after reboot, btrfs has not been able to commit the update to CURRENT to disk in a consistent state, therefore discards the COW data to CURRENT and leaves it in its prior state, which now holds the old data - somehow MANIFEST-010814 has however been deleted, so now CURRENT points to a non existent file. I don't know how leveldb works or where its (f)sync statements are. but I'm guessing it works reliably on ext4 since it's used by many users and I'm the first one reporting this problem with leveldb. Does anyone know if it's leveldb relying on non POSIX semantics that just happen to work out on ext4, or if btrfs COW and atomicity doesn't quite handle multi file updates in a way that is expected by a spec, or by application developers? Thanks, Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
