Thanks very much again!
a) replicate it per your replication factor - what is your replication set to? (single/double/triple?)
my replication is set to single
load 600G data, File System du detects 863G, so the gap of 863-600=263G
so the extra 263G is the total size of below?
- describe information for searchable structures
- some internal free space
- very limited indexes.
All updates in a page in Redwood are initially performed on a copy of the page. The in-page structure only supports marking existing entries as deleted and inserting new entries, so if the page can’t fit the edits then it is rebuilt which will remove the deleted entries. The new page is written to disk, and once committed the pager will redirect reads of the original page ID at the new commit version to the new page, transparently.
For this:
- “in-page structure” means those pages differ from the copy of the page?
- "so if the page can’t fit the edits " means that the free space of current page is not enough and couldn’t hold the the inserting of new entries (tree will be re-organized ) ?
- “then it is rebuilt which will remove the deleted entries.” : after removing the deleted entries, the space will be reuse?
- basing on the process of update in FDB’s Redwood engine , it seems that setting smaller fill-factor could help promote the IOPS performance for update-workload, not just only insert-workload, am I right? could you please help correct me?
Regards,