ext3/ext4 fsync hack (was: openldap.git branch mdb.master updated. 0018eeb2c3b2239c30def9d47c9d194a4ebf35fe)

[Hallvard Breien Furuseth <h.b.furuseth@usit.uio.no>]

On 18/12/14 05:40, openldap-commit2devel@OpenLDAP.org wrote:
> commit 0018eeb2c3b2239c30def9d47c9d194a4ebf35fe
> Author: Howard Chu <hyc@openldap.org>
> Date:   Thu Dec 18 04:38:53 2014 +0000
>
>      Hack for potential ext3/ext4 corruption issue
>
>      Use regular fsync() if we think this commit grew the DB file.

This does not catch all cases:

If the new pages below mt_next_pgno were freed instead of
written, me_size becomes too big.  Later when the file does
grow, me_size may be >= actual filesize so it fdatasync()s.
Similar to b09e46904c1c059bd5086243e3915b6be510e57d
"ITS#7886 fix mdb_copy write size".
We can fix me_size, grow the file anyway (ftruncate), or
give the pages back to mt_next_pgno in mdb_freelist_save().

Another issue: After an MDB_NOSYNC commit, mdb_env_sync()
only fdatasync()s.  It does not know when the file grew.
The planned "group commits" may get the same problem if
the user checkpoints with mdb_env_sync().