umgeher/leveled
0
Fork 0
Code Issues Pull requests Releases Activity Actions

Explain sync option

Browse source
This commit is contained in:
martinsumner 2017-02-26 16:29:55 +00:00
parent d6f4b31632
commit ff31ca2d86
2 changed files with 2 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

2
README.md
View file

@ -94,7 +94,7 @@ Unit and current tests in leveled should run with rebar3. Leveled has been test
{ok, Bookie} = leveled_bookie:book_start(RootPath, LedgerCacheSize, JournalSize, SyncStrategy)
```
This will start a new Bookie. It will start and look for existing data files, under the RootPath, and start empty if none exist. A LedgerCacheSize of 2000, a JournlaSize of 500000000 (500MB) and a SyncStrategy of recovr should work OK.
This will start a new Bookie. It will start and look for existing data files, under the RootPath, and start empty if none exist. A LedgerCacheSize of 2000, a JournalSize of 500000000 (500MB) and a SyncStrategy of recovr should work OK.
The book_start method should respond once startup is complete. The leveled_bookie module includes the full API for external use of the store.

2
docs/FUTURE.md
View file

@ -12,7 +12,7 @@ The store supports all the required Riak backend capabilities. A number of furt
- A bucket size query, which requires traversal only of the Ledger and counts the keys and sums the total on-disk size of the objects within the bucket.
- A PUT flag that allows a truer meaning to the existing DW setting, allowing flushing to disk to be prompted by the need to meet the DW flag, rather than always/never
- A new SW count to operate in parallel to DW, where SW is the number of nodes required to have flushed to disk (not just written to buffer); with SW being configurable to 0 (no vnodes will need to sync this write), 1 (the PUT coordinator will sync, but no other vnodes) or all (all vnodes will be required to sync this write before providing a DW ack). This will allow the expensive disk sync operation to be constrained to the writes for which it is most needed.
- Support for a specific Riak tombstone tag where reaping of tombstones can be deferred (by many days) i.e. so that a 'sort-of-keep' deletion strategy can be followed that will eventually garbage collect without the need to hold pending full deletion state in memory.