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
edddfbe7
Commit
edddfbe7
authored
Oct 18, 2021
by
Kirill Smelkov
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
.
parent
4655b8d3
Changes
2
Hide whitespace changes
Inline
Side-by-side
Showing
2 changed files
with
10 additions
and
14 deletions
+10
-14
wcfs/notes.txt
wcfs/notes.txt
+2
-2
wcfs/wcfs.go
wcfs/wcfs.go
+8
-12
No files found.
wcfs/notes.txt
View file @
edddfbe7
...
...
@@ -57,7 +57,7 @@ Trees _and_ Buckets nodes - would be required.
-> we took the approach where we send invalidation to client about a block
lazily only when the block is actually accessed.
XXX building δFtail lazily along serving fuse reads during scope of one
XXX building δFtail lazily along serving fuse reads during scope of one
XXX kill - fixed
transaction is not trivial and creates concurrency bottlenecks if simple
locking scheme is used. With the main difficulty being to populate tracking set
of δBtree lazily. However as the first approach we can still build complete
...
...
@@ -107,7 +107,7 @@ We can change a mapping while a page from it is under pagefault:
* https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/filemap.c?id=v4.20-rc3-83-g06e68fed3282#n2457
* https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/filemap.c?id=v4.20-rc3-83-g06e68fed3282#n1301
- the filesystem server
upon receiving the read request
can manipulate
- the filesystem server
, upon receiving the read request,
can manipulate
client's address space. This requires to write-lock client->mm->mmap_sem,
but we can be sure it won't deadlock because the kernel releases it
before waiting (see previous point).
...
...
wcfs/wcfs.go
View file @
edddfbe7
...
...
@@ -261,7 +261,7 @@ package main
//
// The invariant helps on invalidation: when δFtail (see below) sees a
// changed oid, it is guaranteed that if the change affects block that was
// ever provided to OS, δFtail will detect that this block has changed.
XXX review
// ever provided to OS, δFtail will detect that this block has changed.
// And if oid relates to a file block but is not in δFtail's tracking set -
// we know that block is not cached and will trigger ZODB load on a future
// file read.
...
...
@@ -308,7 +308,7 @@ package main
// cache for @<rev>/bigfile/file[blk], where
//
// # see below about file.δtail
// # XXX ->
file.BlkRevAt(
#blk, zhead.at)
// # XXX ->
δFtail.BlkRevAt(file,
#blk, zhead.at)
// rev = max(file.δtail.by(#blk)) || min(rev ∈ file.δtail) || zhead.at
//
// - invalidate head/bigfile/file[blk] in OS file cache.
...
...
@@ -339,7 +339,7 @@ package main
// XXX δtail can miss ...
//
// to support initial openings with @at being slightly in the past, we also
// make sure that min(rev) is enough to cover last 10 minutes of history
// make sure that min(rev) is enough to cover last 10 minutes of history
XXX 10m -> 1m ?
// from head/at.
//
// 7) when we receive a FUSE read(#blk) request to a head/bigfile/file, we process it as follows:
...
...
@@ -368,7 +368,7 @@ package main
// rev(blk) ≤ rev'(blk) rev'(blk) = min(^^^)
//
//
//
XXX
we delay recomputing δFtail.BlkRevAt(file, #blk, head) because
//
Note:
we delay recomputing δFtail.BlkRevAt(file, #blk, head) because
// using just cheap revmax estimate can frequently result in all watches
// being skipped.
//
...
...
@@ -425,6 +425,7 @@ package main
// (^) see notes.txt -> "Client cannot be ptraced while under pagefault"
// (%) no need to keep track of ZData - ZBlk1 is always marked as changed on blk data change.
// Wcfs locking organization
//
// As it was said processing ZODB invalidations (see "4") and serving file
...
...
@@ -463,6 +464,7 @@ package main
// WatchLink.byfileMu > BigFileDir.fileMu
// WatchLink.byfileMu > Watch.atMu
// Notation used
//
// δZ - change in ZODB space
...
...
@@ -600,7 +602,7 @@ type BigFileDir struct {
// δ tail of tracked BTree nodes of all BigFiles + -> which file
// (used only for head/, not revX/)
δFmu
sync
.
RWMutex
// zheadMu.W | zheadMu.R + δFmu.X
δFmu
sync
.
RWMutex
// zheadMu.W | zheadMu.R + δFmu.X
XXX kill δFmu
δFtail
*
zdata
.
ΔFtail
}
...
...
@@ -624,15 +626,9 @@ type BigFile struct {
// while populating δFtail lazily
// XXX or then it is not "constant during lifetime of current txn"
// // tail change history of this file.
// //
// // XXX computationally expensive to start - see "Invalidations to wcfs
// // clients are delayed ..." in notes.txt
// δtail *ΔTailI64 // [](rev↑, []#blk)
// blocks that were ever read-accessed (head/ only) XXX locking by bfdir.δFmu ?
// XXX = δFtail.Tracked(f) ?
// XXX goes away if δFtail query returns only tracked blocks
// XXX goes away if δFtail query returns only tracked blocks
(XXX that's not the case)
accessed
setI64
// inflight loadings of ZBigFile from ZODB.
...
...
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