-
Notifications
You must be signed in to change notification settings - Fork 1
/
kvlayout.txt
75 lines (61 loc) · 2.98 KB
/
kvlayout.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
Overall key scheme:
=== inodes ===
prefix 'i' inode -> contains basic attrs and symlink info
prefix 'i' inode \x00 pid1, anything -> info on a lock
prefix 'i' inode \x00 pid2, anything -> info on a lock
prefix 'i' inode \x01 pid1 -> per fuse-process use counter (64 bit LE)
prefix 'i' inode \x01 pid2 -> per fuse-process use counter (64 bit LE)
prefix 'i' inode \x02 xattr0 -> arbitrary number of extended attributes
prefix 'i' inode \x02 xattr1
prefix 'i' inode \x02 xattr2
prefix 'i' inode \xfe inodeattr -> pseudo keys to indicate inode updates
prefix 'd' inode filenameA-> dirents.
prefix 'd' inode filenameB
prefix 'd' inode filenameC
prefix 'f' inode offset0 -> plain block, may be shorter than blocksize if ends in nulls
-> totally null blocks can be omitted
prefix 'f' inode offset2 'z'\x01\x00 -> block compressed with whatever algorithm is assigned to \x00
prefix 'f' inode offset3 'p'\x02\x00... -> key contains 512 bytes of parity for the block
there should be only one kv pair within a given offset(n) to offset(n+1)
range.
prefix 'p' pid -> ProcessTableEntry
The \x00 space for locks is adjacent to the inodes, because in a mandatory
locking system, you'd need to read them along with the inode. So we'll
store them for a single range read.
The \xfe space is to register common partial updates to an inode. For
instance, when reading blocks with noatime, the only thing you need to
know about an inode is existance and the size of it. So read the inode
without a read conflict range, but lay down a read conflict on the
inode size key. Anything changing the size will read/write conflict the
inode, and write conflict the inode size key. So another process only
changing the owner (which will read/write the inode, and write conflict
the inode owner attr) won't conflict all of the ongoing reads.
=== garbage ===
prefix 'g' inode -> indicates that nlinks in the inode has gone to zero,
and it should be check periodically for all of the
usage to have gone to zero, at which time it can be
cleared.
=== pid table ===
prefix 'pl' pid1 -> status of a given fuse process
prefix 'pl' pid2
the status should include an incrementing counter as a heartbeat,
and some host information. each process should update its heartbeat
every reasonable timeout amount of time. (30-60 seconds?)
if processes notice that another pid's entry has stopped updating,
they should delete it. the GC process can confirm the liveness of
all pids it encounters when cleaning up inodes.
similarly processes should watch for updates on their pid entry.
if it is updated or erased, they should react immediately.
=== meta ===
prefix 'M' -> metadata block. filesystem version and blocksize?
inode record
* INodeRecord
* any information necessary for non-file/non-directory things
* contents mutable
* definitely not portable
directory entry
* DirectoryEntry protobuf message
* inode value
* (struct stat).st_mode & S_IFMT
* contents are immutable
* may not be portable