https://bugs.openldap.org/show_bug.cgi?id=9397 --- Comment #2 from github(a)nicwatson.org <github(a)nicwatson.org&gt; --- Thank you for your prompt attention. I took a look at implementing a patch to prevent ftruncate from reducing the filesize. I could use your advice in resolving races. There are two paths to consider to the ftruncate call in mdb_env_map: from mdb_env_open2, and from mdb_env_set_mapsize. In the former case, if the file is the only reader, the file is locked for exclusive use (via a file lock on the first byte of the lock file), so no races are possible. If the file is already open, the issues are the same as the next case. For the user explicitly calling mdb_env_set_mapsize or opening an already-opened file, there's no exclusive lock held, so another process might be in the middle of its own call to ftruncate, and any detection of other readers would itself be racy. So, we either need a new locking scheme for setting the file size, or need a safer (that doesn't reduce the file size) call to make than ftruncate. Taking the write transaction lock was my first guess, but that would prevent a new process from opening a file while a write transaction was held, which seems unacceptable. Another option is we could create a new exclusive file lock from the lockfile. This lock would be held only for the period of time of checking the file size and calling ftruncate. That has backwards compatibility implications. IMHO, this seems like a fundamental problem in the POSIX ftruncate API. Alternatives would be writing a "safe" byte to the end of the map, for example with pwrite(). I'm not really sure what a safe byte would be. (writing 0 bytes does not increase the file size, unfortunately). Another option is using posix_fallocate for the last byte of the map. This would technically force a disk page to be allocated, which wouldn't hurt anything. The downside is availability of the API at all (for example it is not available on MacOS), and that it downgrades to a racy manual implementation if fallocate isn't available (which is I think everything but Linux). On the plus side, the race would be much smaller than it exists today, and completely eliminated on Linux. Thoughts? -- You are receiving this mail because: You are on the CC list for the issue.

https://bugs.openldap.org/show_bug.cgi?id=9397 --- Comment #4 from github(a)nicwatson.org <github(a)nicwatson.org&gt; --- (In reply to Howard Chu from comment #3) ... I have a finite view on the users of LMDB, but I know of 3 libraries built on LMDB this change in contract would impact. It is common (sense) to dynamically increase the map size when the map gets full. We would essentially be asking our downstreams to implement external file locking. I was planning on passing the "excl" value from mdb_env_open2 to a new parameter to mdb_env_map, and only allow the filesize to decrease when excl is True (and the running process has an exclusive lock). This would preserve the existing behavior with a single process user. The file size/ftruncate race still remains though. In fact, any two processes that call ftruncate on the same file will have this problem. Now that I think about it, an fcntl exclusive lock on the first byte of the data file would work (just for the period between checking the file size and ftruncate), and it does somewhat capture the semantics of protecting the file. -- You are receiving this mail because: You are on the CC list for the issue.

https://bugs.openldap.org/show_bug.cgi?id=9397 --- Comment #6 from github(a)nicwatson.org <github(a)nicwatson.org&gt; --- (In reply to Howard Chu from comment #5) HFS+ filesystems on MacOS do not support sparse files. ftruncate allocates (and deallocates) real disk space on these platforms. -- You are receiving this mail because: You are on the CC list for the issue.

https://bugs.openldap.org/show_bug.cgi?id=9397 --- Comment #8 from Howard Chu <hyc(a)openldap.org&gt; --- (In reply to tina from comment #7) There's no danger of corruption if you only resize to grow the DB, which is the only functionality you should need in an active application. Shrinking the DB should only be an administrative action, not a live runtime operation. -- You are receiving this mail because: You are on the CC list for the issue.

https://bugs.openldap.org/show_bug.cgi?id=9397 --- Comment #10 from github(a)nicwatson.org <github(a)nicwatson.org&gt; --- (In reply to Howard Chu from comment #8) "only resize to grow the DB" is impossible without external synchronization. Without an external lock, there's always a window between checking the file size and truncating the file when another process might have done the same. Imagine two processes A and B that both call mdb_env_set_mapsize at the same time on an environment pointing at the same file. Process A calls the function with a size of 20 MiB, process B calls it with a size of 10 MiB. Before the call, the file size was 5 MiB. I believe the follow sequence is possible. Process A: 0. mdb_env_set_mapsize begins Process B: 1. 0. mdb_env_set_mapsize begins Process A: 1. ftruncate (inside mdb_env_set_mapsize)(20MiB) 2. mmap(20MiB) (inside mdb_env_set_mapsize) 3. mdb_env_set_mapsize completes 4. mdb_txn_begin 5. mdb_cursor_put Process B: 6. ftruncate(10MiB) Process A: 7. mdb_txn_commit (bus error due to access past end of file) If step 7 happens before step 6, then we have potential data loss and a corrupted DB if the process A transaction wrote data between the 10MiB and 20 MiB offsets in the file. In other words, you can have two separate processes increasing the map size and still truncate real data from the file and/or bus error. -- You are receiving this mail because: You are on the CC list for the issue.