tahoe-lafs/tahoe-lafs
tahoe-lafs
/
tahoe-lafs
2
0
Fork 0
Code Issues Pull Requests 23 Packages Projects Releases 1 Wiki Activity

docs: update architecture.txt 's section on the vdrive a.k.a. filesystem layer 

Remove some obsolete parts (correct at the time, now incorrect), change terminology to reflect my preference: s/vdrive/filesystem/ and s/dirnode/directory/, and make a few other small changes.
This commit is contained in:
Zooko O'Whielacronx 2008-10-06 14:05:00 -07:00
parent 09341a969a
commit dc2a114290
1 changed files with 24 additions and 30 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

54
docs/architecture.txt
View File

@ -16,7 +16,7 @@ nodes.
The middle layer is the decentralized filesystem: a directed graph in The middle layer is the decentralized filesystem: a directed graph in
which the intermediate nodes are directories and the leaf nodes are which the intermediate nodes are directories and the leaf nodes are
files. The leaf nodes contain only the file data -- they contain no files. The leaf nodes contain only the file data -- they contain no
metadata about the file other than the length. The edges leading to metadata about the file other than the length in bytes. The edges leading to
leaf nodes have metadata attached to them about the file they point leaf nodes have metadata attached to them about the file they point
to. Therefore, the same file may be associated with different to. Therefore, the same file may be associated with different
metadata if it is dereferenced through different edges. metadata if it is dereferenced through different edges.
@ -274,41 +274,34 @@ in the same facility, so the helper-to-storage-server bandwidth is huge.
See "helper.txt" for details about the upload helper. See "helper.txt" for details about the upload helper.
VDRIVE and DIRNODES: THE VIRTUAL DRIVE LAYER THE FILESYSTEM LAYER
The "virtual drive" layer is responsible for mapping human-meaningful The "filesystem" layer is responsible for mapping human-meaningful
pathnames (directories and filenames) to pieces of data. The actual bytes pathnames (directories and filenames) to pieces of data. The actual bytes
inside these files are referenced by capability, but the "vdrive" is where inside these files are referenced by capability, but the filesystem layer is
the directory names, file names, and metadata are kept. where the directory names, file names, and metadata are kept.
In the current release, the virtual drive is a graph of "dirnodes". Each The filesystem layer is a graph of directories. Each directory contains a table
dirnode represents a single directory, and thus contains a table of named of named children. These children are either other directories or files. All
children. These children are either other dirnodes or actual files. All children are referenced by their capability.
children are referenced by their capability. Each client creates a "private
vdrive" dirnode at startup. The clients also receive access to a "global
vdrive" dirnode from the central introducer/vdrive server, which is shared
between all clients and serves as an easy demonstration of having multiple
writers for a single dirnode.
The dirnode itself has two forms of capability: one is read-write and the A directory has two forms of capability: read-write caps and read-only caps. The
other is read-only. The table of children inside the dirnode has a read-write table of children inside the directory has a read-write and read-only capability
and read-only capability for each child. If you have a read-only capability for each child. If you have a read-only capability for a given directory, you will
for a given dirnode, you will not be able to access the read-write capability not be able to access the read-write capability of its children. This results
of the children. This results in "transitively read-only" dirnode access. in "transitively read-only" directory access.
By having two different capabilities, you can choose which you want to share By having two different capabilities, you can choose which you want to share
with someone else. If you create a new directory and share the read-write with someone else. If you create a new directory and share the read-write
capability for it with a friend, then you will both be able to modify its capability for it with a friend, then you will both be able to modify its
contents. If instead you give them the read-only capability, then they will contents. If instead you give them the read-only capability, then they will
*not* be able to modify the contents. Any capability that you receive can be *not* be able to modify the contents. Any capability that you receive can be
attached to any dirnode that you can modify, so very powerful linked in to any directory that you can modify, so very powerful
shared+published directory structures can be built from these components. shared+published directory structures can be built from these components.
This structure enable individual users to have their own personal space, with This structure enable individual users to have their own personal space, with
links to spaces that are shared with specific other users, and other spaces links to spaces that are shared with specific other users, and other spaces
that are globally visible. Eventually the application layer will present that are globally visible.
these pieces in a way that allows the sharing of a specific file or the
creation of a "virtual CD" as easily as dragging a folder onto a user icon.
LEASES, REFRESHING, GARBAGE COLLECTION, QUOTAS LEASES, REFRESHING, GARBAGE COLLECTION, QUOTAS
@ -468,7 +461,7 @@ but can accomplish none of the following three attacks:
not granted them access not granted them access
2) violate consistency: the attacker convinces you that the wrong data is 2) violate consistency: the attacker convinces you that the wrong data is
actually the data you were intending to retrieve actually the data you were intending to retrieve
3) violate mutability: the attacker gets to modify a dirnode (either the 3) violate mutability: the attacker gets to modify a directory (either the
pathnames or the file contents) to which you have not given them pathnames or the file contents) to which you have not given them
mutability rights mutability rights
@ -510,8 +503,8 @@ A likely enhancement is the ability to use distinct encryption keys for each
file, avoiding the file-correlation attacks at the expense of increased file, avoiding the file-correlation attacks at the expense of increased
storage consumption. This is known as "non-convergent" encoding. storage consumption. This is known as "non-convergent" encoding.
The capability-based security model is used throughout this project. dirnode The capability-based security model is used throughout this project. Directory
operations are expressed in terms of distinct read and write capabilities. operations are expressed in terms of distinct read- and write- capabilities.
Knowing the read-capability of a file is equivalent to the ability to read Knowing the read-capability of a file is equivalent to the ability to read
the corresponding data. The capability to validate the correctness of a file the corresponding data. The capability to validate the correctness of a file
is strictly weaker than the read-capability (possession of read-capability is strictly weaker than the read-capability (possession of read-capability
@ -519,11 +512,12 @@ automatically grants you possession of validate-capability, but not vice
versa). These capabilities may be expressly delegated (irrevocably) by simply versa). These capabilities may be expressly delegated (irrevocably) by simply
transferring the relevant secrets. transferring the relevant secrets.
The application layer can provide whatever security/access model is desired, The application layer can provide whatever access model is desired, built on
but we expect the first few to also follow capability discipline: rather than top of this capability access model. The first big user of this system so far
user accounts with passwords, each user will get a write-cap to their private is allmydata.com. The allmydata.com access model currently works like a normal
dirnode, and the presentation layer will give them the ability to break off web site, using username and password to give a user access to her virtual
pieces of this vdrive for delegation or sharing with others on demand. drive. In addition, allmydata.com users can share individual files (using a
file sharing interface built on top of the immutable file read capabilities).
RELIABILITY RELIABILITY