Rotate compaction output at user key boundary #375
Conversation
so that keys with same user key will not spread over multiple tables in same level, level 1 or above. Level compaction, except for level-0, don't pick overlapping tables. So if we produce overlapping tables in user key level, it is possible that file with newer version user key got picked and compacted to next level. Now, the invariant that Version::Get depends on is broken, Version::Get is broken. The vulnerability of this approach is that a malicious client can retain a snapshhot and do large number of writes to same key, which can cause huge sorted table generated. LevelDB is a library that embedded in other application. I think it should be the application's responsibility to keep snapshhot from malicious clients. Picking overlapping tables in all level compactions is another approach to solve this problem. I think this approach may violate the algorithm this implementation implies.
kezhuw
force-pushed
the
rotate_compaction_at_user_key_boundary
branch
from
849345d
to
2546ba5
Compare
|
I write a gist https://gist.github.com/kezhuw/2e53639ca46b89016ea54703e61734cd to show this. This gist contains several files: rotate.diff, rotate.before.log, rotate.after.log, rotate.filesize.log. You can apply rotate.diff to leveldb source directory to create a test program to produce the log file attached in this gist. It contains a macro The test program constantly puts a key to LevelDB and allocates snapshots from that db without releasing. It also logs some compaction info to stderr, which I redirect to rotate.before.log and rotate.after.log in this gist.
This is Line 47 from rotate.before.log. It says that user key of file 62's largest key is same with file 63's smallest key. The key in file 62 has sequence 71, which is bigger than file 63's, which is 70. This means that key in file 62 is newer than key in file 63.
This is Line 74-76 from rotate.before.log. It says that file 62 is be compacting to level 2, while file 63 is not! According to Line 47, newer entry in file 62 got compacted to next level, while its older variant remains in younger level. If we try to get that key with snapshot 71, we will hit file 63, not file 62. This pull request only rotate compaction outputs in user key boundary. Keys with same user key will never got spread over multiple tables in same level above level-0. The side effect is that it may produce file exceed file size limitation. Sadly, this pull request can't pass ci due to this side effect. rotate.after.log is produced by program with this pacth applied. rotate.filesize.log is output from |
so that keys with same user key will not spread over multiple tables in
same level, level 1 or above.
Level compaction, except for level-0, don't pick overlapping tables. So
if we produce overlapping tables in user key level, it is possible that
file with newer version user key got picked and compacted to next level.
Now, the invariant that Version::Get depends on is broken, Version::Get
is broken.
The vulnerability of this approach is that a malicious client can retain
a snapshhot and do large number of writes to same key, which can cause
huge sorted table generated. LevelDB is a library that embedded in other
application. I think it should be the application's responsibility to
keep snapshhot from malicious clients.
Picking overlapping tables in all level compactions is another approach
to solve this problem. I think this approach may violate the algorithm
this implementation implies.