Loading ...
Sorry, an error occurred while loading the content.

Laptop Versus Axe

Expand Messages
  • zookog
    Greetings, people of the decentralization group! Here is the highlight of my presentation at CodeCon last weekend. CodeCon s prime directive is that every
    Message 1 of 9 , Apr 23, 2009
    • 0 Attachment
      Greetings, people of the decentralization group!

      Here is the highlight of my presentation at CodeCon last weekend. CodeCon's prime directive is that every presentation has to have a live demo of working code, and that the presenter has to be an author of that code.

      For my demo, I leaned an axe against the speaker's podium, strapped safety goggles around my neck, and then I showed three laptops on stage, each running a Tahoe node, and then uploaded a movie file to the Tahoe grid made up of those three nodes. (This means the file gets automatically encrypted, digitally signed, and erasure-coded.)

      Then I explained that after uploading your movie to the Tahoe grid, you might turn off your Tahoe node and go away. And while you are gone, something BAD might happen...

      http://testgrid.allmydata.org:3567/uri/URI:DIR2-RO:j74uhg25nwdpjpacl6rkat2yhm:kav7ijeft5h7r7rxdp5bgtlt3viv32yabqajkrdykozia5544jqa/wiki.html#%5B%5BLaptop%20Versus%20Axe%5D%5D

      :-)

      Regards,

      Zooko
    • Lucas Gonze
      I pity the axe. So what s the plan for Tahoe, Zooko? Are you working on getting it bundled with unix distributions? Is your strategy to aim at low-churn
      Message 2 of 9 , Apr 24, 2009
      • 0 Attachment
        I pity the axe.

        So what's the plan for Tahoe, Zooko? Are you working on getting it
        bundled with unix distributions? Is your strategy to aim at low-churn
        servers or high-churn clients?

        zookog wrote:
        > Greetings, people of the decentralization group!
        >
        > Here is the highlight of my presentation at CodeCon last weekend. CodeCon's prime directive is that every presentation has to have a live demo of working code, and that the presenter has to be an author of that code.
        >
        > For my demo, I leaned an axe against the speaker's podium, strapped safety goggles around my neck, and then I showed three laptops on stage, each running a Tahoe node, and then uploaded a movie file to the Tahoe grid made up of those three nodes. (This means the file gets automatically encrypted, digitally signed, and erasure-coded.)
        >
        > Then I explained that after uploading your movie to the Tahoe grid, you might turn off your Tahoe node and go away. And while you are gone, something BAD might happen...
        >
        > http://testgrid.allmydata.org:3567/uri/URI:DIR2-RO:j74uhg25nwdpjpacl6rkat2yhm:kav7ijeft5h7r7rxdp5bgtlt3viv32yabqajkrdykozia5544jqa/wiki.html#%5B%5BLaptop%20Versus%20Axe%5D%5D
        >
        > :-)
        >
        > Regards,
        >
        > Zooko
        >
        >
        >
        > ------------------------------------
        >
        > Yahoo! Groups Links
        >
        >
        >
        >
      • Zooko O'Whielacronx
        ... So, yeah, allmydata.com stopped funding new Tahoe development a few months ago [1]. Tahoe, the Longlived Axe-tolerant File System, is now a purely
        Message 3 of 9 , Apr 24, 2009
        • 0 Attachment
          > So what's the plan for Tahoe, Zooko? Are you working on getting it
          > bundled with unix distributions? Is your strategy to aim at low-churn
          > servers or high-churn clients?

          So, yeah, allmydata.com stopped funding new Tahoe development a few
          months ago [1]. Tahoe, the Longlived Axe-tolerant File System, is now
          a purely volunteer-driven community project. The current version is
          already functional and reliable -- it has been in production use in
          allmydata.com for more than a year, storing all of the allmydata.com
          customer files. Our goals do indeed focus on getting Tahoe included
          in Debian, Fedora, Gentoo, and Ubuntu this summer [2].

          I'm not sure I understand your question about churning servers and
          clients. Tahoe is explicitly designed for low-churn servers -- I've
          become increasingly skeptical of the whole notion of relying on
          high-churn servers for reliable long-term storage. They don't have to
          be expensive reliable servers, though -- allmydata.com uses cheap
          commodity servers and other Tahoe deployments use people's home PCs.

          The issue of "churn" is irrelevant to Tahoe clients -- nobody else
          relies on other clients so they can come and go as they please.

          Thanks for asking!

          [1] http://allmydata.org/pipermail/tahoe-dev/2009-March/001461.html #
          tahoe needs funding! (and Zooko is available for work!)
          [2] http://allmydata.org/pipermail/tahoe-dev/2009-April/001627.html #
          questions about development priorities for Tahoe-LAFS, summer 2009
        • Lucas Gonze
          Are you expecting it to be used by nodes that cross an administrative boundary?
          Message 4 of 9 , Apr 28, 2009
          • 0 Attachment
            Are you expecting it to be used by nodes that cross an administrative
            boundary?


            Zooko O'Whielacronx wrote:
            >> So what's the plan for Tahoe, Zooko? Are you working on getting it
            >> bundled with unix distributions? Is your strategy to aim at low-churn
            >> servers or high-churn clients?
            >
            > So, yeah, allmydata.com stopped funding new Tahoe development a few
            > months ago [1]. Tahoe, the Longlived Axe-tolerant File System, is now
            > a purely volunteer-driven community project. The current version is
            > already functional and reliable -- it has been in production use in
            > allmydata.com for more than a year, storing all of the allmydata.com
            > customer files. Our goals do indeed focus on getting Tahoe included
            > in Debian, Fedora, Gentoo, and Ubuntu this summer [2].
            >
            > I'm not sure I understand your question about churning servers and
            > clients. Tahoe is explicitly designed for low-churn servers -- I've
            > become increasingly skeptical of the whole notion of relying on
            > high-churn servers for reliable long-term storage. They don't have to
            > be expensive reliable servers, though -- allmydata.com uses cheap
            > commodity servers and other Tahoe deployments use people's home PCs.
            >
            > The issue of "churn" is irrelevant to Tahoe clients -- nobody else
            > relies on other clients so they can come and go as they please.
            >
            > Thanks for asking!
            >
            > [1] http://allmydata.org/pipermail/tahoe-dev/2009-March/001461.html #
            > tahoe needs funding! (and Zooko is available for work!)
            > [2] http://allmydata.org/pipermail/tahoe-dev/2009-April/001627.html #
            > questions about development priorities for Tahoe-LAFS, summer 2009
            >
            >
            > ------------------------------------
            >
            > Yahoo! Groups Links
            >
            >
            >
            >
          • Zooko O'Whielacronx
            ... That s a very good question. The minimal answer is Yes . The short answer is that you don t rely on the storage servers for confidentiality (all data is
            Message 5 of 9 , Apr 29, 2009
            • 0 Attachment
              On Tue, Apr 28, 2009 at 10:52 PM, Lucas Gonze <lucas@...> wrote:
              >
              > Are you expecting it to be used by nodes that cross an administrative
              > boundary?

              That's a very good question. The minimal answer is "Yes". The short
              answer is that you don't rely on the storage servers for
              confidentiality (all data is encrypted) nor for integrity (all data is
              either hashed if immutable or signed if mutable), but you do rely on
              the storage servers to be somewhat reliable. If any K (typically 3)
              out of M (typically 10) of the storage servers are reachable and
              well-behaved then you can use your file, so you don't require *high*
              reliability from your servers, but you do require a certain reasonable
              amount of reliability. Certainly it would fail if you just picked ten
              random strangers from the Internet and hoped that at least three of
              them would loyally store your file for you and make their servers
              reachable when you wanted it. (Which is fairly close to what Mojo
              Nation and Mnet and non-darknet-Freenet attempted.)

              So this means that you don't have to entrust your secrets and the
              integrity of your data to the server operators, but you do need some
              reason to think that the server operators will keep maintaining the
              servers and letting you connect to them in the future. The two kinds
              of deployment so far are the allmydata.com use case in which a company
              operates hundreds of servers and customers pay a monthly fee to get
              access, and the friendnet (what Ian Clarke named "darknet") use case,
              where a group of friends all let each other use their computers out of
              love.

              Regards,

              Zooko
            • Lucas Gonze
              Zooko O Whielacronx wrote: The two kinds ... This makes me think of a hybrid model where there s a coop of businesses or sophisticated friends. Maybe 5-100
              Message 6 of 9 , May 1, 2009
              • 0 Attachment
                Zooko O'Whielacronx wrote:
                The two kinds
                > of deployment so far are the allmydata.com use case in which a company
                > operates hundreds of servers and customers pay a monthly fee to get
                > access, and the friendnet (what Ian Clarke named "darknet") use case,
                > where a group of friends all let each other use their computers out of
                > love.

                This makes me think of a hybrid model where there's a coop of businesses
                or sophisticated friends. Maybe 5-100 companies.

                What's the latency like? How does it feel on an application level to
                use this instead of a typical SAN?
              • David Barrett
                That s interesting. Just curious, is it easy to deploy this in a web-facing manner? For example, at Expensify we store a bunch of receipt images. We
                Message 7 of 9 , May 1, 2009
                • 0 Attachment
                  That's interesting. Just curious, is it easy to deploy this in a
                  web-facing manner? For example, at Expensify we store a bunch of
                  receipt images. We currently do it with S3, and they're fine, but I'm
                  always interested in alternatives. If I got a handful of dedicated
                  servers scattered around the world, all with huge hard drives, could I
                  easily configure Tahoe in conjunction with a webserver to:

                  1) Upload a receipt to any server using HTTP PUT

                  2) Fetch a receipt image from any server using HTTP GET

                  3) Automatically balance redundant storage such that DNS load balancing
                  "just works" for both uploads and downloads

                  Does it do this out of the box by some miracle? If coding is involved,
                  can you give me a quick overview of the steps I'd need to take?
                  (standalone C++, lighttpd/PHP, anything is fine.)

                  Thanks!

                  -david

                  Lucas Gonze wrote:
                  > Zooko O'Whielacronx wrote:
                  > The two kinds
                  >> of deployment so far are the allmydata.com use case in which a company
                  >> operates hundreds of servers and customers pay a monthly fee to get
                  >> access, and the friendnet (what Ian Clarke named "darknet") use case,
                  >> where a group of friends all let each other use their computers out of
                  >> love.
                  >
                  > This makes me think of a hybrid model where there's a coop of businesses
                  > or sophisticated friends. Maybe 5-100 companies.
                  >
                  > What's the latency like? How does it feel on an application level to
                  > use this instead of a typical SAN?
                  >
                  >
                  >
                  > ------------------------------------
                  >
                  > Yahoo! Groups Links
                  >
                  >
                  >
                • Zooko O'Whielacronx
                  ... Yeah! Because a company is more reliable and available and has a lot more capital than one of your friends, but you don t want to put all your eggs in one
                  Message 8 of 9 , May 2, 2009
                  • 0 Attachment
                    On Fri, May 1, 2009 at 8:17 PM, Lucas Gonze <lucas@...> wrote:
                    >
                    > This makes me think of a hybrid model where there's a coop of businesses
                    > or sophisticated friends. Maybe 5-100 companies.

                    Yeah! Because a company is more reliable and available and has a lot
                    more capital than one of your friends, but you don't want to put all
                    your eggs in one corporate basket.


                    > What's the latency like? How does it feel on an application level to
                    > use this instead of a typical SAN?

                    Hm, well here are some measurements:

                    http://allmydata.org/tahoe-figleaf-graph/hanford.allmydata.com-tahoe_speedstats_delay.html


                    But probably you'll get a better idea by experimenting with it:

                    http://testgrid.allmydata.org:3567/uri/URI%3ADIR2%3Adjrdkfawoqihigoett4g6auz6a%3Ajx5mplfpwexnoqff7y5e4zjus4lidm76dcuarpct7cckorh2dpgq/

                    (Warning: that grid is populated by "whoever reads
                    http://allmydata.org and connects", so I can't vouch for its
                    performance.)


                    Regards,

                    Zooko
                  • Zooko O'Whielacronx
                    ... Well, yeah it is pretty close to this already. The Tahoe web API listens for PUT and GET, as documented here:
                    Message 9 of 9 , May 2, 2009
                    • 0 Attachment
                      On Fri, May 1, 2009 at 8:24 PM, David Barrett <dbarrett@...> wrote:
                      >
                      > 1) Upload a receipt to any server using HTTP PUT
                      ...
                      > 2) Fetch a receipt image from any server using HTTP GET
                      ...
                      > 3) Automatically balance redundant storage such that DNS load balancing
                      > "just works" for both uploads and downloads
                      >
                      > Does it do this out of the box by some miracle?

                      Well, yeah it is pretty close to this already. The Tahoe web API
                      listens for PUT and GET, as documented here:

                      http://allmydata.org/trac/tahoe/browser/docs/frontends/webapi.txt

                      (This is similar but not identical to the S3 API. I keep thinking we
                      should try to make them more similar, or put an S3 layer on the Tahoe
                      web api... If you experiment with converting from S3 to Tahoe please
                      let us know what you learn.)

                      Give it a try!

                      Regards,

                      Zooko
                    Your message has been successfully submitted and would be delivered to recipients shortly.