liuis / leveldb

Automatically exported from code.google.com/p/leveldb
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

Need an option to tell LevelDB to perform fsync periodly #152

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Open a database
2. ls -l in the database directory
3. Perform several Put operation
4. Wait for 10 seconds
5. ls -l in the same directory

What is the expected output? What do you see instead?

The size of *.log should change. But it is not, all files remain unmodified.

What version of the product are you using? On what operating system?

1.8.0, Linux

Please provide any additional information below.

* Feature required

Provide an option(sync, etc) when Open a database, if it is set to 1(one 
second), a background thread will perform fsync on opened files every second.

As Linux kernel actually commits writes after 30 seconds, this is a long time, 
may cause a lot data loss on machine failure.

Original issue reported on code.google.com by wuzuy...@gmail.com on 22 Mar 2013 at 5:30

GoogleCodeExporter commented 9 years ago
First, leveldb does something unusual that might be worth knowing about: the 
size of the *.log file is not expected to change very fast since the log file 
is pre-enlarged and then mmapped and written to directly using memcpy.

About your feature request: there are already ways to achieve this.
(a) Kernel tuning flags should allow tweaking the 30 second delay downwards (I 
think the parameter you are looking for is /proc/sys/vm/dirty_expire_centisecs).

(b) If you want to msync() just the leveldb data, you can achieve this by 
having a background thread of your own that just does a sync=true innocuous 
write to the database.  Deleting a non-existent key or writing an empty string 
to a key you do not use should suffice.

Given that there are existing mechanisms to achieve what you want, any feature 
we add would just be a convenience.  So I am not inclined to add the complexity 
of such a feature to leveldb.

Original comment by san...@google.com on 25 Mar 2013 at 11:22