This means current clients (outside content) that use third_party/leveldatabase and env_chromium.* now need DEPS access to //storage/common/leveldb ? 

Seems fine, but maybe run that past a top-level owner; so far, I think //storage has been mostly for web-platform-related storage (quota, fileapi, websql, blobs), right?

jsbell@: yes, you have a point, and I'm not really a fan of requiring the leveldb users to add two dependencies. If this code were to be refactored, but left in third_party/leveldatabase then what do you think is the best namespace?

1) leveldb_env
2) leveldb::chrome
3) chrome::leveldb
4) other

Adding to the pile of things to fix: Mutex members should be mutex_, not mu_.

Also, if we'd do //storage/common/leveldb, we could have that export the //third_party/leveldatabase dependency. I'm generally not a fan of exported deps, but in this case using //storage/common/leveldb really means code wants leveldb.

Re #c2 above. I decided to go with the leveldb_chrome namespace in https://chromium-review.googlesource.com/c/chromium/src/+/651574. We can change that when this is done if we come up with a better solution.

Also, Copyright banner says, "Copyright (c) ???? The LevelDB Authors". We should change this to "Chromium Authors".

Overridden virtual functions, like ChromiumEnv::DeleteFile should have "override" and delete "virtual".

leveldb_env::WriteBufferSize() is only used by content/browser/indexed_db/leveldb/leveldb_database.cc. If there are no plans to use this elsewhere move this to indexed_db/leveldb.

Do we want to rename the unit test program?: env_chromium_unittests

There's a fair amount of memory-infra code. Would be nice if this can be consolidated somehow.