Changeset 2cad199 in trunk


Ignore:
Timestamp:
2017-06-06T17:01:52Z (8 years ago)
Author:
Brian Warner <warner@…>
Branches:
master
Children:
0977e52, b8010ad
Parents:
958f79d4 (diff), 705dc85 (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the (diff) links above to see all the changes relative to each parent.
Message:

Merge PR380: LAFS = "Least-Authority File Store"

Closes tahoe-lafs/tahoe-lafs#380
refs ticket:2345

Files:
15 edited

Legend:

Unmodified
Added
Removed

  • TabularUnified docs/about.rst

    r958f79d4 r2cad199  
    6868has direct attached storage (typically one or more hard disks).  A "gateway"
    6969communicates with storage nodes, and uses them to provide access to the
    70 file store over protocols such as HTTP(S), SFTP or FTP.
     70grid over protocols such as HTTP(S), SFTP or FTP.
    7171
    7272Note that you can find "client" used to refer to gateway nodes (which act as
    … …  
    9595the gateway can view and modify the user's data (the user *relies on* the
    9696gateway for confidentiality and integrity), but the advantage is that the
    97 user can access the file store with a client that doesn't have the gateway
    98 software installed, such as an Internet kiosk or cell phone.
     97user can access the Tahoe-LAFS grid with a client that doesn't have the
     98gateway software installed, such as an Internet kiosk or cell phone.
    9999
    100100Access Control

  • TabularUnified docs/architecture.rst

    r958f79d4 r2cad199  
    11115.  `Server Selection`_
    12126.  `Swarming Download, Trickling Upload`_
    13 7.  `The Filesystem Layer`_
     137.  `The File Store Layer`_
    14148.  `Leases, Refreshing, Garbage Collection`_
    15159.  `File Repairer`_
    … …  
    2323(See the `docs/specifications directory`_ for more details.)
    2424
    25 There are three layers: the key-value store, the filesystem, and the
     25There are three layers: the key-value store, the file store, and the
    2626application.
    2727
    … …  
    3434a few bytes and as large as tens of gigabytes are in common use.
    3535
    36 The middle layer is the decentralized filesystem: a directed graph in which
     36The middle layer is the decentralized file store: a directed graph in which
    3737the intermediate nodes are directories and the leaf nodes are files. The leaf
    3838nodes contain only the data -- they contain no metadata other than the length
    … …  
    4141different metadata if it is referred to through different edges.
    4242
    43 The top layer consists of the applications using the filesystem.
     43The top layer consists of the applications using the file store.
    4444Allmydata.com used it for a backup service: the application periodically
    45 copies files from the local disk onto the decentralized filesystem. We later
     45copies files from the local disk onto the decentralized file store. We later
    4646provide read-only access to those files, allowing users to recover them.
    4747There are several other applications built on top of the Tahoe-LAFS
    48 filesystem (see the RelatedProjects_ page of the wiki for a list).
     48file store (see the RelatedProjects_ page of the wiki for a list).
    4949
    5050.. _docs/specifications directory: https://github.com/tahoe-lafs/tahoe-lafs/tree/master/docs/specifications
    … …  
    158158self-authenticating, meaning that nobody can trick you into accepting a file
    159159that doesn't match the capability you used to refer to that file. The
    160 filesystem layer (described below) adds human-meaningful names atop the
     160file store layer (described below) adds human-meaningful names atop the
    161161key-value layer.
    162162
    … …  
    320320
    321321
    322 The Filesystem Layer
     322The File Store Layer
    323323====================
    324324
    325 The "filesystem" layer is responsible for mapping human-meaningful pathnames
     325The "file store" layer is responsible for mapping human-meaningful pathnames
    326326(directories and filenames) to pieces of data. The actual bytes inside these
    327 files are referenced by capability, but the filesystem layer is where the
     327files are referenced by capability, but the file store layer is where the
    328328directory names, file names, and metadata are kept.
    329329
    330 The filesystem layer is a graph of directories. Each directory contains a
     330The file store layer is a graph of directories. Each directory contains a
    331331table of named children. These children are either other directories or
    332332files. All children are referenced by their capability.
    … …  
    354354======================================
    355355
    356 When a file or directory in the virtual filesystem is no longer referenced,
    357 the space that its shares occupied on each storage server can be freed,
    358 making room for other shares. Tahoe-LAFS uses a garbage collection ("GC")
    359 mechanism to implement this space-reclamation process. Each share has one or
    360 more "leases", which are managed by clients who want the file/directory to be
     356When a file or directory in the file store is no longer referenced, the space
     357that its shares occupied on each storage server can be freed, making room for
     358other shares. Tahoe-LAFS uses a garbage collection ("GC") mechanism to
     359implement this space-reclamation process. Each share has one or more
     360"leases", which are managed by clients who want the file/directory to be
    361361retained. The storage server accepts each share for a pre-defined period of
    362362time, and is allowed to delete the share if all of the leases are cancelled
    … …  
    379379permanent data loss (affecting the preservation of the file). Hard drives
    380380crash, power supplies explode, coffee spills, and asteroids strike. The goal
    381 of a robust distributed filesystem is to survive these setbacks.
     381of a robust distributed file store is to survive these setbacks.
    382382
    383383To work against this slow, continual loss of shares, a File Checker is used
    … …  
    487487
    488488The application layer can provide whatever access model is desired, built on
    489 top of this capability access model. The first big user of this system so far
    490 is allmydata.com. The allmydata.com access model currently works like a
    491 normal web site, using username and password to give a user access to her
    492 "virtual drive". In addition, allmydata.com users can share individual files
    493 (using a file sharing interface built on top of the immutable file read
    494 capabilities).
     489top of this capability access model.
    495490
    496491

  • TabularUnified docs/configuration.rst

    r958f79d4 r2cad199  
    677677======================
    678678
    679 The Tahoe client process can run a variety of frontend file-access protocols.
    680 You will use these to create and retrieve files from the virtual filesystem.
    681 Configuration details for each are documented in the following
    682 protocol-specific guides:
     679The Tahoe-LAFS client process can run a variety of frontend file access
     680protocols. You will use these to create and retrieve files from the
     681Tahoe-LAFS file store. Configuration details for each are documented in
     682the following protocol-specific guides:
    683683
    684684HTTP
    … …  
    696696
    697697    The main ``tahoe`` executable includes subcommands for manipulating the
    698     filesystem, uploading/downloading files, and creating/running Tahoe
     698    file store, uploading/downloading files, and creating/running Tahoe
    699699    nodes. See :doc:`frontends/CLI` for details.
    700700

  • TabularUnified docs/frontends/CLI.rst

    r958f79d4 r2cad199  
    1111
    12123.  `Node Management`_
    13 4.  `Filesystem Manipulation`_
     134.  `File Store Manipulation`_
    1414
    1515    1.  `Starting Directories`_
    … …  
    2525
    2626Tahoe-LAFS provides a single executable named "``tahoe``", which can be used
    27 to create and manage client/server nodes, manipulate the filesystem, and
     27to create and manage client/server nodes, manipulate the file store, and
    2828perform several debugging/maintenance tasks. This executable is installed
    2929into your virtualenv when you run ``pip install tahoe-lafs``.
    … …  
    3636
    3737* node management: create a client/server node, start/stop/restart it
    38 * filesystem manipulation: list files, upload, download, unlink, rename
     38* file store manipulation: list files, upload, download, unlink, rename
    3939* debugging: unpack cap-strings, examine share files
    4040
    … …  
    121121
    122122
    123 Filesystem Manipulation
     123File Store Manipulation
    124124=======================
    125125
    126 These commands let you exmaine a Tahoe-LAFS filesystem, providing basic
     126These commands let you exmaine a Tahoe-LAFS file store, providing basic
    127127list/upload/download/unlink/rename/mkdir functionality. They can be used as
    128128primitives by other scripts. Most of these commands are fairly thin wrappers
    129129around web-API calls, which are described in :doc:`webapi`.
    130130
    131 By default, all filesystem-manipulation commands look in ``~/.tahoe/`` to
     131By default, all file store manipulation commands look in ``~/.tahoe/`` to
    132132figure out which Tahoe-LAFS node they should use. When the CLI command makes
    133133web-API calls, it will use ``~/.tahoe/node.url`` for this purpose: a running
    … …  
    143143--------------------
    144144
    145 As described in :doc:`../architecture`, the Tahoe-LAFS distributed filesystem
     145As described in :doc:`../architecture`, the Tahoe-LAFS distributed file store
    146146consists of a collection of directories and files, each of which has a
    147147"read-cap" or a "write-cap" (also known as a URI). Each directory is simply a
    … …  
    180180``root_dir.cap`` file.
    181181
    182 The Tahoe-LAFS CLI commands use the same path syntax as ``scp`` and
     182The Tahoe-LAFS CLI commands use a similar path syntax to ``scp`` and
    183183``rsync`` -- an optional ``ALIAS:`` prefix, followed by the pathname or
    184184filename. Some commands (like "``tahoe cp``") use the lack of an alias to
    185185mean that you want to refer to a local file, instead of something from the
    186 Tahoe-LAFS filesystem. Another way to indicate this is to start the
    187 pathname with "./", "~/", "~username/", or "/".
     186Tahoe-LAFS file store. Another way to indicate this is to start the
     187pathname with "./", "~/", "~username/", or "/". On Windows, aliases
     188cannot be a single character, so that it is possible to distinguish a
     189path relative to an alias from a path starting with a local drive specifier.
    188190
    189191When you're dealing a single starting directory, the ``tahoe:`` alias is
    … …  
    334336``tahoe ls subdir``
    335337
    336  This lists a subdirectory of your filesystem.
     338 This lists a subdirectory of your file store.
    337339
    338340``tahoe webopen``

  • TabularUnified docs/frontends/FTP-and-SFTP.rst

    r958f79d4 r2cad199  
    4343All Tahoe-LAFS client nodes can run a frontend SFTP server, allowing regular
    4444SFTP clients (like ``/usr/bin/sftp``, the ``sshfs`` FUSE plugin, and many
    45 others) to access the virtual filesystem. They can also run an FTP server,
    46 so FTP clients (like ``/usr/bin/ftp``, ``ncftp``, and others) can too. These
     45others) to access the file store. They can also run an FTP server, so FTP
     46clients (like ``/usr/bin/ftp``, ``ncftp``, and others) can too. These
    4747frontends sit at the same level as the web-API interface.
    4848

  • TabularUnified docs/frontends/webapi.rst

    r958f79d4 r2cad199  
    7272======================================
    7373
    74 As described in :doc:`../architecture`, each file and directory in a Tahoe
    75 virtual filesystem is referenced by an identifier that combines the
     74As described in :doc:`../architecture`, each file and directory in a
     75Tahoe-LAFS file store is referenced by an identifier that combines the
    7676designation of the object with the authority to do something with it (such as
    7777read or modify the contents). This identifier is called a "read-cap" or
    … …  
    9494operations are required to have no side-effects.
    9595
    96 PUT is used to upload new objects into the filesystem, or to replace an
     96PUT is used to upload new objects into the file store, or to replace an
    9797existing link or the contents of a mutable file. DELETE is used to unlink
    9898objects from directories. Both PUT and DELETE are required to be idempotent:
    … …  
    108108also be done with a POST.
    109109
    110 Tahoe's web API is designed for two different kinds of consumer. The first is
    111 a program that needs to manipulate the virtual file system. Such programs are
     110Tahoe-LAFS' web API is designed for two different kinds of consumer. The
     111first is a program that needs to manipulate the file store. Such programs are
    112112expected to use the RESTful interface described above. The second is a human
    113 using a standard web browser to work with the filesystem. This user is given
    114 a series of HTML pages with links to download files, and forms that use POST
    115 actions to upload, rename, and unlink files.
     113using a standard web browser to work with the file store. This user is
     114presented with a series of HTML pages with links to download files, and forms
     115that use POST actions to upload, rename, and unlink files.
    116116
    117117When an error occurs, the HTTP response code will be set to an appropriate
    … …  
    333333
    334334Now that we know how to build URLs that refer to files and directories in a
    335 Tahoe virtual filesystem, what sorts of operations can we do with those URLs?
     335Tahoe-LAFS file store, what sorts of operations can we do with those URLs?
    336336This section contains a catalog of GET, PUT, DELETE, and POST operations that
    337337can be performed on these URLs. This set of operations are aimed at programs
    … …  
    420420
    421421 This uploads a file, and produces a file-cap for the contents, but does not
    422  attach the file into the filesystem. No directories will be modified by
     422 attach the file into the file store. No directories will be modified by
    423423 this operation. The file-cap is returned as the body of the HTTP response.
    424424
    … …  
    436436 Create a new empty directory and return its write-cap as the HTTP response
    437437 body. This does not make the newly created directory visible from the
    438  filesystem. The "PUT" operation is provided for backwards compatibility:
     438 file store. The "PUT" operation is provided for backwards compatibility:
    439439 new code should use POST.
    440440
    … …  
    808808under that name.
    809809
    810 Note however, that if the edge in the Tahoe filesystem points to a mutable
    811 file and the contents of that mutable file is changed, then the
     810Note however, that if the edge in the Tahoe-LAFS file store points to a
     811mutable file and the contents of that mutable file is changed, then the
    812812'tahoe':'linkmotime' value on that edge will *not* be updated, since the
    813813edge itself wasn't updated -- only the mutable file was.
    … …  
    836836"tahoe backup" command (in Tahoe v1.3.0 and later) to set the 'mtime' and
    837837'ctime' values when backing up files from a local filesystem into the
    838 Tahoe filesystem. As of Tahoe v1.4.0, the set_children API cannot be used
    839 to set anything under the 'tahoe' key of the metadata dict -- if you
     838Tahoe-LAFS file store. As of Tahoe v1.4.0, the set_children API cannot be
     839used to set anything under the 'tahoe' key of the metadata dict -- if you
    840840include 'tahoe' keys in your 'metadata' arguments then it will silently
    841841ignore those keys.
    … …  
    865865
    8668661. You might be confused about whether it reflects the time of the creation
    867    of a link in the Tahoe filesystem (by a version of Tahoe < v1.7.0) or a
    868    timestamp copied in by "tahoe backup" from a local filesystem.
     867   of a link in the Tahoe-LAFS file store (by a version of Tahoe < v1.7.0)
     868   or a timestamp copied in by "tahoe backup" from a local filesystem.
    869869
    8708702. You might be confused about whether it is a copy of the file creation
    … …  
    896896
    897897 This attaches a child object (either a file or directory) to a specified
    898  location in the virtual filesystem. The child object is referenced by its
     898 location in the Tahoe-LAFS file store. The child object is referenced by its
    899899 read- or write- cap, as provided in the HTTP request body. This will create
    900900 intermediate directories as necessary.
    … …  
    10091009This section describes the HTTP operations that provide support for humans
    10101010running a web browser. Most of these operations use HTML forms that use POST
    1011 to drive the Tahoe node. This section is intended for HTML authors who want
    1012 to write web pages that contain forms and buttons which manipulate the Tahoe
    1013 filesystem.
     1011to drive the Tahoe-LAFS node. This section is intended for HTML authors who
     1012want to write web pages containing user interfaces for manipulating the
     1013Tahoe-LAFS file store.
    10141014
    10151015Note that for all POST operations, the arguments listed can be provided
    … …  
    11081108``POST /uri?t=mkdir``
    11091109
    1110  This creates a new empty directory, but does not attach it to the virtual
    1111  filesystem.
     1110 This creates a new empty directory, but does not attach it to any other
     1111 directory in the Tahoe-LAFS file store.
    11121112
    11131113 If a "redirect_to_result=true" argument is provided, then the HTTP response
    … …  
    11511151
    11521152 This uploads a file, and produces a file-cap for the contents, but does not
    1153  attach the file into the filesystem. No directories will be modified by
    1154  this operation.
     1153 attach the file to any directory in the Tahoe-LAFS file store. That is, no
     1154 directories will be modified by this operation.
    11551155
    11561156 The file must be provided as the "file" field of an HTML encoded form body,
    … …  
    17001700 reachable from the starting directory. The path will be slash-joined, and
    17011701 the filecap/dircap will contain a link to the object in question. This page
    1702  gives immediate access to every object in the virtual filesystem subtree.
     1702 gives immediate access to every object in the file store subtree.
    17031703
    17041704 This operation uses the same ophandle= mechanism as deep-check. The
    … …  
    18341834
    18351835The portion of the web namespace that begins with "/uri" (and "/named") is
    1836 dedicated to giving users (both humans and programs) access to the Tahoe
    1837 virtual filesystem. The rest of the namespace provides status information
    1838 about the state of the Tahoe node.
     1836dedicated to giving users (both humans and programs) access to the Tahoe-LAFS
     1837file store. The rest of the namespace provides status information about the
     1838state of the Tahoe-LAFS node.
    18391839
    18401840``GET /``   (the root page)
    … …  
    18441844 Node information: library versions, local nodeid, services being provided.
    18451845
    1846  Filesystem Access Forms: create a new directory, view a file/directory by
     1846 File store access forms: create a new directory, view a file/directory by
    18471847                          URI, upload a file (unlinked), download a file by
    18481848                          URI.
    18491849
    1850  Grid Status: introducer information, helper information, connected storage
     1850 Grid status: introducer information, helper information, connected storage
    18511851              servers.
    18521852
    … …  
    19951995
    19961996Summary: use explicit file- and dir- caps whenever possible, to reduce the
    1997 potential for surprises when the filesystem structure is changed.
    1998 
    1999 Tahoe provides a mutable filesystem, but the ways that the filesystem can
    2000 change are limited. The only thing that can change is that the mapping from
    2001 child names to child objects that each directory contains can be changed by
    2002 adding a new child name pointing to an object, removing an existing child name,
    2003 or changing an existing child name to point to a different object.
    2004 
    2005 Obviously if you query Tahoe for information about the filesystem and then act
    2006 to change the filesystem (such as by getting a listing of the contents of a
    2007 directory and then adding a file to the directory), then the filesystem might
    2008 have been changed after you queried it and before you acted upon it.  However,
    2009 if you use the URI instead of the pathname of an object when you act upon the
    2010 object, then the only change that can happen is if the object is a directory
    2011 then the set of child names it has might be different. If, on the other hand,
    2012 you act upon the object using its pathname, then a different object might be in
    2013 that place, which can result in more kinds of surprises.
     1997potential for surprises when the file store structure is changed.
     1998
     1999Tahoe-LAFS provides a mutable file store, but the ways that the store can
     2000change are limited. The only things that can change are:
     2001 * the mapping from child names to child objects inside mutable directories
     2002   (by adding a new child, removing an existing child, or changing an
     2003   existing child to point to a different object)
     2004 * the contents of mutable files
     2005
     2006Obviously if you query for information about the file store and then act
     2007to change it (such as by getting a listing of the contents of a mutable
     2008directory and then adding a file to the directory), then the store might
     2009have been changed after you queried it and before you acted upon it.
     2010However, if you use the URI instead of the pathname of an object when you
     2011act upon the object, then it will be the same object; only its contents
     2012can change (if it is mutable). If, on the other hand, you act upon the
     2013object using its pathname, then a different object might be in that place,
     2014which can result in more kinds of surprises.
    20142015
    20152016For example, suppose you are writing code which recursively downloads the
    … …  
    20192020then it recurses into that directory. Now, if the download and the recurse
    20202021actions are performed using the child's name, then the results might be
    2021 wrong, because for example a child name that pointed to a sub-directory when
     2022wrong, because for example a child name that pointed to a subdirectory when
    20222023you listed the directory might have been changed to point to a file (in which
    2023 case your attempt to recurse into it would result in an error and the file
    2024 would be skipped), or a child name that pointed to a file when you listed the
    2025 directory might now point to a sub-directory (in which case your attempt to
    2026 download the child would result in a file containing HTML text describing the
    2027 sub-directory!).
    2028 
    2029 If your recursive algorithm uses the uri of the child instead of the name of
     2024case your attempt to recurse into it would result in an error), or a child
     2025name that pointed to a file when you listed the directory might now point to
     2026a subdirectory (in which case your attempt to download the child would result
     2027in a file containing HTML text describing the subdirectory!).
     2028
     2029If your recursive algorithm uses the URI of the child instead of the name of
    20302030the child, then those kinds of mistakes just can't happen. Note that both the
    20312031child's name and the child's URI are included in the results of listing the

  • TabularUnified docs/garbage-collection.rst

    r958f79d4 r2cad199  
    1414========
    1515
    16 When a file or directory in the virtual filesystem is no longer referenced,
     16When a file or directory in a Tahoe-LAFS file store is no longer referenced,
    1717the space that its shares occupied on each storage server can be freed,
    1818making room for other shares. Tahoe currently uses a garbage collection

  • TabularUnified docs/man/man1/tahoe.1

    r958f79d4 r2cad199  
    22.SH NAME
    33.PP
    4 tahoe - Secure distributed filesystem.
     4tahoe - Secure distributed file store.
    55.SH SYNOPSIS
    66.PP
    … …  
    131131.RS
    132132.RE
    133 .SS USING THE FILESYSTEM
     133.SS USING THE FILE STORE
    134134.TP
    135135.B \f[B]mkdir\f[]

  • TabularUnified docs/proposed/README.lossmodel

    r958f79d4 r2cad199  
    11The lossmodel.lyx file is the source document for an in-progress paper
    2 that analyzes the probability of losing files stored in a Tahoe
    3 Least-acces File System under various scenarios.  It describes:
     2that analyzes the probability of losing files stored in a Tahoe-LAFS
     3file store under various scenarios.  It describes:
    44
    551.  How to estimate peer reliabilities, based on peer MTBF failure

  • TabularUnified docs/running.rst

    r958f79d4 r2cad199  
    117117Prefer the command-line? Run “``tahoe --help``” (the same command-line
    118118tool that is used to start and stop nodes serves to navigate and use the
    119 decentralized filesystem). To get started, create a new directory and
     119decentralized file store). To get started, create a new directory and
    120120mark it as the 'tahoe:' alias by running “``tahoe create-alias tahoe``”.
    121121Once you've done that, you can do “``tahoe ls tahoe:``” and “``tahoe cp
    122 LOCALFILE tahoe:foo.txt``” to work with your filesystem. The Tahoe-LAFS
     122LOCALFILE tahoe:foo.txt``” to work with your file store. The Tahoe-LAFS
    123123CLI uses similar syntax to the well-known scp and rsync tools. See
    124124:doc:`frontends/CLI` for more details.

  • TabularUnified docs/specifications/dirnodes.rst

    r958f79d4 r2cad199  
    99provides operations that accept files and upload them to the grid, creating
    1010a URI in the process which securely references the file's contents.
    11 The middle layer is the filesystem, creating a structure of directories and
    12 filenames resembling the traditional unix/windows filesystems. The top layer
    13 is the application layer, which uses the lower layers to provide useful
     11The middle layer is the file store, creating a structure of directories and
     12filenames resembling the traditional Unix or Windows filesystems. The top
     13layer is the application layer, which uses the lower layers to provide useful
    1414services to users, like a backup application, or a way to share files with
    1515friends.
    1616
    17 This document examines the middle layer, the "filesystem".
     17This document examines the middle layer, the "file store".
    1818
    19191.  `Key-value Store Primitives`_
    20 2.  `Filesystem goals`_
    21 3.  `Dirnode goals`_
     202.  `File Store Goals`_
     213.  `Dirnode Goals`_
    22224.  `Dirnode secret values`_
    23235.  `Dirnode storage format`_
    … …  
    5454 data = get(mutable_uri)
    5555
    56 Filesystem Goals
     56File Store Goals
    5757================
    5858
    59 The main goal for the middle (filesystem) layer is to give users a way to
     59The main goal for the middle (file store) layer is to give users a way to
    6060organize the data that they have uploaded into the grid. The traditional way
    6161to do this in computer filesystems is to put this data into files, give those
    … …  
    114114(and *not* read-write access) to its children.
    115115
    116 Relative to the previous "vdrive-server" based scheme, the current
     116Relative to the previous "vdrive server"-based scheme, the current
    117117distributed dirnode approach gives better availability, but cannot guarantee
    118118updateness quite as well, and requires far more network traffic for each
    … …  
    290290guess the length of the child names (or at least their sum). From this, the
    291291attacker may be able to build up a graph with the same shape as the plaintext
    292 filesystem, but with unlabeled edges and unknown file contents.
     292file store, but with unlabeled edges and unknown file contents.
    293293
    294294
    … …  
    340340
    341341When a backup program is run for the first time, it needs to copy a large
    342 amount of data from a pre-existing filesystem into reliable storage. This
    343 means that a large and complex directory structure needs to be duplicated in
    344 the dirnode layer. With the one-object-per-dirnode approach described here,
    345 this requires as many operations as there are edges in the imported
    346 filesystem graph.
     342amount of data from a pre-existing local filesystem into reliable storage.
     343This means that a large and complex directory structure needs to be
     344duplicated in the dirnode layer. With the one-object-per-dirnode approach
     345described here, this requires as many operations as there are edges in the
     346imported filesystem graph.
    347347
    348348Another approach would be to aggregate multiple directories into a single
    … …  
    405405keep alive.
    406406
    407 After each change to the user's vdrive, the client creates a manifest and
     407After each change to the user's file store, the client creates a manifest and
    408408looks for differences from their previous version. Anything which was removed
    409409prompts the client to send out lease-cancellation messages, allowing the data
    … …  
    423423
    424424The biggest benefit of this dirnode approach is that sharing individual
    425 directories is almost trivial. Alice creates a subdirectory that she wants to
    426 use to share files with Bob. This subdirectory is attached to Alice's
    427 filesystem at "~alice/share-with-bob". She asks her filesystem for the
    428 read-write directory URI for that new directory, and emails it to Bob. When
    429 Bob receives the URI, he asks his own local vdrive to attach the given URI,
    430 perhaps at a place named "~bob/shared-with-alice". Every time either party
    431 writes a file into this directory, the other will be able to read it. If
    432 Alice prefers, she can give a read-only URI to Bob instead, and then Bob will
    433 be able to read files but not change the contents of the directory. Neither
    434 Alice nor Bob will get access to any files above the mounted directory: there
    435 are no 'parent directory' pointers. If Alice creates a nested set of
    436 directories, "~alice/share-with-bob/subdir2", and gives a read-only URI to
    437 share-with-bob to Bob, then Bob will be unable to write to either
    438 share-with-bob/ or subdir2/.
     425directories is almost trivial. Alice creates a subdirectory that she wants
     426to use to share files with Bob. This subdirectory is attached to Alice's
     427file store at "alice:shared-with-bob". She asks her file store for the
     428read-only directory URI for that new directory, and emails it to Bob. When
     429Bob receives the URI, he attaches the given URI into one of his own
     430directories, perhaps at a place named "bob:shared-with-alice". Every time
     431Alice writes a file into this directory, Bob will be able to read it.
     432(It is also possible to share read-write URIs between users, but that makes
     433it difficult to follow the `Prime Coordination Directive`_ .) Neither
     434Alice nor Bob will get access to any files above the mounted directory:
     435there are no 'parent directory' pointers. If Alice creates a nested set of
     436directories, "alice:shared-with-bob/subdir2", and gives a read-only URI to
     437shared-with-bob to Bob, then Bob will be unable to write to either
     438shared-with-bob/ or subdir2/.
     439
     440.. _`Prime Coordination Directive`: ../write_coordination.rst
    439441
    440442A suitable UI needs to be created to allow users to easily perform this
    441 sharing action: dragging a folder their vdrive to an IM or email user icon,
    442 for example. The UI will need to give the sending user an opportunity to
    443 indicate whether they want to grant read-write or read-only access to the
    444 recipient. The recipient then needs an interface to drag the new folder into
    445 their vdrive and give it a home.
     443sharing action: dragging a folder from their file store to an IM or email
     444user icon, for example. The UI will need to give the sending user an
     445opportunity to indicate whether they want to grant read-write or read-only
     446access to the recipient. The recipient then needs an interface to drag the
     447new folder into their file store and give it a home.
    446448
    447449Revocation

  • TabularUnified docs/specifications/uri.rst

    r958f79d4 r2cad199  
    14143.  `Internal Usage of URIs`_
    1515
    16 Each file and directory in a Tahoe filesystem is described by a "URI". There
    17 are different kinds of URIs for different kinds of objects, and there are
    18 different kinds of URIs to provide different kinds of access to those
     16Each file and directory in a Tahoe-LAFS file store is described by a "URI".
     17There are different kinds of URIs for different kinds of objects, and there
     18are different kinds of URIs to provide different kinds of access to those
    1919objects. Each URI is a string representation of a "capability" or "cap", and
    2020there are read-caps, write-caps, verify-caps, and others.
    … …  
    4242=========
    4343
    44 The lowest layer of the Tahoe architecture (the "grid") is reponsible for
    45 mapping URIs to data. This is basically a distributed hash table, in which
    46 the URI is the key, and some sequence of bytes is the value.
     44The lowest layer of the Tahoe architecture (the "key-value store") is
     45reponsible for mapping URIs to data. This is basically a distributed
     46hash table, in which the URI is the key, and some sequence of bytes is
     47the value.
    4748
    4849There are two kinds of entries in this table: immutable and mutable. For
    … …  
    5455filled with different pieces of data at different times.
    5556
    56 It is important to note that the "files" described by these URIs are just a
    57 bunch of bytes, and that **no** filenames or other metadata is retained at
    58 this layer. The vdrive layer (which sits above the grid layer) is entirely
    59 responsible for directories and filenames and the like.
     57It is important to note that the values referenced by these URIs are just
     58sequences of bytes, and that **no** filenames or other metadata is retained at
     59this layer. The file store layer (which sits above the key-value store layer)
     60is entirely responsible for directories and filenames and the like.
    6061
    6162CHK URIs
    … …  
    165166==============
    166167
    167 The grid layer provides a mapping from URI to data. To turn this into a graph
    168 of directories and files, the "vdrive" layer (which sits on top of the grid
    169 layer) needs to keep track of "directory nodes", or "dirnodes" for short.
    170 :doc:`dirnodes` describes how these work.
     168The key-value store layer provides a mapping from URI to data. To turn this
     169into a graph of directories and files, the "file store" layer (which sits on
     170top of the key-value store layer) needs to keep track of "directory nodes",
     171or "dirnodes" for short. :doc:`dirnodes` describes how these work.
    171172
    172173Dirnodes are contained inside mutable files, and are thus simply a particular

  • TabularUnified docs/write_coordination.rst

    r958f79d4 r2cad199  
    1515write.
    1616
    17 If mutable parts of a filesystem are accessed via sshfs, only a single
     17If mutable parts of a file store are accessed via sshfs, only a single
    1818sshfs mount should be used. There may be data loss if mutable files or
    1919directories are accessed via two sshfs mounts, or written both via sshfs

  • TabularUnified src/allmydata/scripts/cli.py

    r958f79d4 r2cad199  
    1010_default_nodedir = get_default_nodedir()
    1111
    12 class FilesystemOptions(BaseOptions):
     12class FileStoreOptions(BaseOptions):
    1313    optParameters = [
    1414        ["node-url", "u", None,
    … …  
    4747
    4848
    49 class MakeDirectoryOptions(FilesystemOptions):
     49class MakeDirectoryOptions(FileStoreOptions):
    5050    optParameters = [
    5151        ("format", None, None, "Create a directory with the given format: SDMF or MDMF (case-insensitive)"),
    … …  
    6262    description = """Create a new directory, either unlinked or as a subdirectory."""
    6363
    64 class AddAliasOptions(FilesystemOptions):
     64class AddAliasOptions(FileStoreOptions):
    6565    def parseArgs(self, alias, cap):
    6666        self.alias = argv_to_unicode(alias)
    … …  
    7272    description = """Add a new alias for an existing directory."""
    7373
    74 class CreateAliasOptions(FilesystemOptions):
     74class CreateAliasOptions(FileStoreOptions):
    7575    def parseArgs(self, alias):
    7676        self.alias = argv_to_unicode(alias)
    … …  
    8181    description = """Create a new directory and add an alias for it."""
    8282
    83 class ListAliasesOptions(FilesystemOptions):
     83class ListAliasesOptions(FileStoreOptions):
    8484    synopsis = "[options]"
    8585    description = """Display a table of all configured aliases."""
    … …  
    8888    ]
    8989
    90 class ListOptions(FilesystemOptions):
     90class ListOptions(FileStoreOptions):
    9191    optFlags = [
    9292        ("long", "l", "Use long format: show file sizes, and timestamps."),
    … …  
    125125    The size of mutable files or unknown objects is shown as '?'.
    126126
    127     The date/time shows when this link in the Tahoe filesystem was
    128     last modified.
     127    The date/time shows when this link in the Tahoe grid was last
     128    modified.
    129129    """
    130130
    131 class GetOptions(FilesystemOptions):
     131class GetOptions(FileStoreOptions):
    132132    def parseArgs(self, arg1, arg2=None):
    133133        # tahoe get FOO |less            # write to stdout
    … …  
    157157    """
    158158
    159 class PutOptions(FilesystemOptions):
     159class PutOptions(FileStoreOptions):
    160160    optFlags = [
    161161        ("mutable", "m", "Create a mutable file instead of an immutable one (like --format=SDMF)"),
    … …  
    203203    """
    204204
    205 class CpOptions(FilesystemOptions):
     205class CpOptions(FileStoreOptions):
    206206    optFlags = [
    207207        ("recursive", "r", "Copy source directory recursively."),
    … …  
    250250    """
    251251
    252 class UnlinkOptions(FilesystemOptions):
     252class UnlinkOptions(FileStoreOptions):
    253253    def parseArgs(self, where):
    254254        self.where = argv_to_unicode(where)
    … …  
    261261    description = "Remove a named file from its parent directory."
    262262
    263 class MvOptions(FilesystemOptions):
     263class MvOptions(FileStoreOptions):
    264264    def parseArgs(self, frompath, topath):
    265265        self.from_file = argv_to_unicode(frompath)
    … …  
    280280    """
    281281
    282 class LnOptions(FilesystemOptions):
     282class LnOptions(FileStoreOptions):
    283283    def parseArgs(self, frompath, topath):
    284284        self.from_file = argv_to_unicode(frompath)
    … …  
    312312    pass
    313313
    314 class BackupOptions(FilesystemOptions):
     314class BackupOptions(FileStoreOptions):
    315315    optFlags = [
    316316        ("verbose", "v", "Be noisy about what is happening."),
    … …  
    381381    TO/Archives/(new) TO/Latest'."""
    382382
    383 class WebopenOptions(FilesystemOptions):
     383class WebopenOptions(FileStoreOptions):
    384384    optFlags = [
    385385        ("info", "i", "Open the t=info page for the file"),
    … …  
    395395    page."""
    396396
    397 class ManifestOptions(FilesystemOptions):
     397class ManifestOptions(FileStoreOptions):
    398398    optFlags = [
    399399        ("storage-index", "s", "Only print storage index strings, not pathname+cap."),
    … …  
    410410    starting point."""
    411411
    412 class StatsOptions(FilesystemOptions):
     412class StatsOptions(FileStoreOptions):
    413413    optFlags = [
    414414        ("raw", "r", "Display raw JSON data instead of parsed"),
    … …  
    422422    given starting point."""
    423423
    424 class CheckOptions(FilesystemOptions):
     424class CheckOptions(FileStoreOptions):
    425425    optFlags = [
    426426        ("raw", None, "Display raw JSON data instead of parsed."),
    … …  
    438438    found."""
    439439
    440 class DeepCheckOptions(FilesystemOptions):
     440class DeepCheckOptions(FileStoreOptions):
    441441    optFlags = [
    442442        ("raw", None, "Display raw JSON data instead of parsed."),

  • TabularUnified src/allmydata/scripts/runner.py

    r958f79d4 r2cad199  
    4545                    + GROUP("Debugging")
    4646                    +   debug.subCommands
    47                     + GROUP("Using the filesystem")
     47                    + GROUP("Using the file store")
    4848                    +   cli.subCommands
    4949                    +   magic_folder_cli.subCommands
Note: See TracChangeset for help on using the changeset viewer.