leveldb
leveldb copied to clipboard
google
[FR] readonly mode
Please add a new parameter during database opening to make it only readable, in case big/expensive database is used or database is on a CD/DVD.
This would also make it possible to open it within multiple processes (LOCK file wont be created). It would also help with power interruption caused corruption. eg https://groups.google.com/g/leveldb/c/YvszWNio2-Q
Access denied could be returned with write/compaction operation. I don't mind if leveldb dies because of content changed on disk.
We provide further tooling around software that makes use of LevelDB. In our use case, one or more processes must be able to read the database but do not need to make any changes.
A readonly mode feature would be enormously helpful to us.
The LOCK file would still be needed to prevent unintended write opens, or opens of an already locked db. Only it should use type F_RDLCK instead of F_WRLCK.
Disk could be mounted as readonly, I'm happy if it fails with segfault if content changes on disk, since we know what we are doing.
The
LOCKfile would still be needed to prevent unintended write opens, or opens of an already locked db. Only it should use typeF_RDLCKinstead ofF_WRLCK.
Good idea, it would prevent the file from being written to by another process which could interfere with the read-only.
I think this would allow apps to ship with read-only databases that could be installed in /usr/share for example without having to make a copy for every user or app-launch in order to access the static data.
one way to achieve the open in read only mode is to write own Env object which provides copy on write operations, when new files are stored in memory (mem-env) and original files are just read,
one way to achieve the open in read only mode is to write own Env object which provides copy on write operations, when new files are stored in memory (mem-env) and original files are just read,
Thanks for the suggestion. I just looked into the Environment class and what it's for, and I think it's a brilliant idea. Hopefully, if a write returns a failure, leveldb just rejects the Put, but stays consistent, if not, the copy-on-write idea would work quite well I think.
Thanks for the suggestion. I just looked into the Environment class and what it's for, and I think it's a brilliant idea. Hopefully, if a write returns a failure, leveldb just rejects the
Put, but stays consistent, if not, the copy-on-write idea would work quite well I think.
Unfortunately the database writes to files when opened. It performs maintenance, for example it reconstructs the log and compacts the manifest. This always writes several files before you can use the database. Therefore, the "COW" path is the only one that works.
I have tried this implementation. I recommend it as an inspiration, think of it as experimental code. Probably the biggest difficulty was in the implementation of the GetChildren function, where I have to simulate the state of the virtual directory, for example to keep track of deleted or renamed files.
https://github.com/ondra-novak/docdb/blob/main/src/docdb/readonly.h