ModelTypeStore/LevelDB holds actual data that has no other local copy. As such, it cannot be freely deleted as the directory/sqllite database is currently. Right now we do delete it, and this needs to change. We layout of data currently looks like

.../Profile/
.../Profile/Sync Data/
.../Profile/Sync Data/SyncData.sqlite3
.../Profile/Sync Data/SyncData.sqlite3-journal
.../Profile/Sync Data/LevelDB/
.../Profile/Sync Data/LevelDB/<many files>

We have logic that completely removes this folder in two places:

https://cs.chromium.org/chromium/src/components/browser_sync/profile_sync_service.cc?l=184
https://cs.chromium.org/chromium/src/components/sync/driver/glue/sync_backend_host_core.cc?l=653


There are a couple of options for what to do here:

We could move the LevelDB out of the Sync Data folder. This raises the question, what should we name it? "LevelDB" is probably not a great top level folder in the profile folder. Some suggestions we've seen so far

.../Profile/LevelDB/
.../Profile/Syncable Data/
.../Profile/Shared LevelDB/
.../Profile/Model Type Store/
.../Profile/SharedDB/
.../Profile/Sync Data.LevelDB/
.../Profile/USS Sync Data/
.../Profile/LevelDB Store/

Part of the ambiguity is about what will this store eventually hold? One could imagine in the future that we may want to expand the purpose of this store past just model types integrating with sync. The overhead of having your own LevelDB to store a tiny amount of data is not insignificant.

On the other hand, maybe even this is not generic enough. It is possible that we may not want to put all ModelTypeStore integrating types into the same LevelDB for performance reasons. They maybe have drastically different access patterns that could conflict. In which case, maybe we want sub-folders for each specific LevelDB. There could be a default one that you get if you don't specify an extra qualifier, but you would be able to control it during model type initialization.

.../Profile/Shared LevelDB/Default/
.../Profile/Shared LevelDB/Bookmarks/
.../Profile/Shared LevelDB/Passwords/


However, neither of the above two generalizations may ever occur, and wasting time worrying about them may be pointless. From another perspective, it would be ideal if we didn't have to create a new top level folder for each profile. Instead, what if we kept the ModelTypeStore LevelDB in the Sync Data folder, and just got slightly smarter when deleting, and only removed the sqllite files. As long as we are reasonably confident we can always remove the sqllite files, and never remove the LevelDB ones, this should work.


If we knew we were going to introduce another storage years ago when we first added the sqllite storage, it would be been convenient if we placed all the files in their own sub folder

.../Profile/Sync Data/sqllite/SyncData.sqllite3
.../Profile/Sync Data/sqllite/SyncData.sqllite3-journal

We theoretically could try to move the existing sqllite files into such a structure, but our current feeling is that the risk is quite great, and the benefits would be extremely small. So the sqllite files will be left as is.