Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
W
wendelin.core
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Labels
Merge Requests
0
Merge Requests
0
Analytics
Analytics
Repository
Value Stream
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Commits
Open sidebar
Kirill Smelkov
wendelin.core
Commits
b984e690
Commit
b984e690
authored
3 years ago
by
Kirill Smelkov
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
.
parent
32b26ae7
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
41 additions
and
3 deletions
+41
-3
wcfs/internal/zdata/δftail.go
wcfs/internal/zdata/δftail.go
+41
-3
No files found.
wcfs/internal/zdata/δftail.go
View file @
b984e690
...
@@ -19,8 +19,46 @@
...
@@ -19,8 +19,46 @@
package
zdata
package
zdata
// XXX note about ΔFtail organization: queries results are built on the fly to
// ΔFtail provides ZBigFile-level history tail.
// avoid complexity of recomputing vδF on tracking set change.
//
// It translates ZODB object-level changes to information about which blocks of
// which ZBigFile were modified, and provides service to query that information.
// See ΔFtail class documentation for details.
//
//
// ΔFtail organization
//
// ΔFtail leverages
//
// - ΔBtail to track changes to ZBigFile.blktab BTree, and
// - ΔZtail to track changes to ZBlk objects and to ZBigFile object itself.
//
// then every query merges ΔBtail and ΔZtail data on the fly to provide
// ZBigFile-level result.
//
// Merging on the fly, contrary to computing and maintaining vδF data, is done
// to avoid complexity of recomputing vδF when tracking set changes. Most of
// ΔFtail complexity is, thus, located in ΔBtail, which implements BTree diff
// and handles complexity of recomputing vδB when set of tracked blocks
// changes.
//
// Changes to ZBigFile object indicate epochs. Epochs could be
//
// - file creation or deletion,
// - change of ZBigFile.blksize,
// - change of ZBigFile.blktab to point to another BTree.
//
// Epochs represent major changes to file history where file is assumed to
// change so dramatically, that practically it can be considered to be a
// "whole" change. In particular, WCFS, upon seeing a ZBigFile epoch,
// invalidates all data in corresponding OS-level cache for the file.
//
// The only historical data, that ΔFtail maintains by itself, is history of
// epochs. That history does not need to be recomputed when more blocks become
// tracked and is thus easy to maintain. It also can be maintained only in
// ΔFtail because ΔBtail and ΔZtail does not "know" anything about ZBigFile.
//
// XXX concurrency
import
(
import
(
"context"
"context"
...
@@ -78,7 +116,7 @@ type setOid = set.Oid
...
@@ -78,7 +116,7 @@ type setOid = set.Oid
// .rev↑
// .rev↑
// {}blk | EPOCH
// {}blk | EPOCH
//
//
// XXX concurrent use
// XXX concurrent use
.
//
//
// See also zodb.ΔTail and xbtree.ΔBtail
// See also zodb.ΔTail and xbtree.ΔBtail
type
ΔFtail
struct
{
type
ΔFtail
struct
{
...
...
This diff is collapsed.
Click to expand it.
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment