Skip to Content.
Sympa Menu

bluesky - the mercury file system

bluesky AT lists.ibiblio.org

Subject: Global-Scale Distributed Storage Systems

List archive

Chronological Thread  
  • From: "Josh" <josh AT mercuryfs.net>
  • To: "'Global-Scale Distributed Storage Systems'" <bluesky AT franklin.oit.unc.edu>
  • Cc: "Steven Torres \(E-mail\)" <steven.torres AT oracle.com>, "Lana Akamine \(E-mail\)" <lana AT valinux.com>, "Charles \(E-mail\)" <charles AT mercuryfs.net>
  • Subject: the mercury file system
  • Date: Mon, 30 Jul 2001 19:12:16 -0700


True! However, I hope to entice the home users because of the other
features, such as security and async mirroring (what will make The Internet
as Primary Disk scenario a reality). In the beginning, ISPs, universities,
and large corporations will be the first. My thoughts are to get it deployed
at the ISPs first (make their features into ver 1.0), because of the cost
savings to them. MFS has a major advantage over all the existing caching
methods (that I know of). Here's a link to an email that touches on that
subject. http://www.mercuryfs.net/essence3.htm

My goal is to make true telecommuting possible. If I can keep it together as
a single standard, and obsolete NFS, it can happen. With MFS, if you were to
map a drive letter to the office, via a modem, and run Microsoft office off
of your server at work, it will be slow the first time only. The permanent
caching feature makes a lot of other features possible. It also has a lot of
promise for fault tolerance.

My ultimate goal is The Anywhere PC scenario. I'm convinced there will be
enough demand for that type of functionality, that the rest of the system
will be adopted. I want anybody to be able to use almost any PC to access
the same desktop. The only variable is speed. This cant be accomplished just
a file system, but it's the main challenge that I see. I figure Java can do
the rest.

The main difference with MFS is that it accesses a file by its data, using a
formula that can be extracted from the data and URL. By doing it this way,
the provider is irrelevant. Security, the MFS hierarchy, and time do not
apply to this method. The p2p performance kicks in because anybody can
provide that file (via MFS handle). When you login, you upload your 10,000
most recently accessed MFS handles to "My Group" which is either your LAN or
your ISP. In the background it continues to update the inventory of what you
have downloaded since logging in. This way, the entire group can benefit
from your file accesses, thus keeping traffic local to My Group. Because MFS
handles do not indicate what the file is, there is a level of privacy here.
I've also figured out a method to trust your neighbors, while keeping their
identity nearly anonymous. That way, should your trust list be obtained, its
next to useless. With the privacy issue and technical issues dealt with, I
think it will really dominate in p2p environments. MFS is a hybrid between
client/sever and peer to peer. It has the advantages of both. It utilizes
storage far more efficiently than client/server, yet retains its centralness
that should allow it to scale in a linear fashion. It's got the performance
of peer to peer because the servers are not the bottleneck, unlike
client/server. With location independence, if a server is busy it will
forward the request to another server/client that's not. It's designed to
run on anything. From a technical perspective, I see no reason why it can't
emulate all the others. (at least not yet)

- josh

-----Original Message-----
From: Bram Cohen [mailto:bram AT gawth.com]
Sent: Monday, July 30, 2001 6:43 PM
To: Global-Scale Distributed Storage Systems
Subject: RE: i've got a design you guys would be interested in

On Sun, 29 Jul 2001, Josh wrote:

> To be honest, I've never heard of ocean store. Thanks, I will look it up
> immediately. I found out about freenet via an attorney. I've been so
focused
> on the design that I haven't read up on all the others... yet.. As for the
> presentation, you probably need the shockwave player, the flash player
won't

> do it. The link to it is at my site, www.mercuryfs.net/presentations.

I poked around your site, and get the impression you're spinning your main
advantage is downloading content from the local network, thus saving costs
for the ISP.

Others have this idea as well, but I think it's going after the wrong
market. The customer of a p2p application is the end user. End users
really, really don't care about costs to their ISP. They might care a bit
about latency, although that's already toast for napster, gnutella,
freenet, bittorrent, and just about everything else. They also might care
about download time, but the bottleneck is going to be the bandwidth of
their net connection.

There are exceptions to this, such as students at very large universities
and people in very large companies, who have much faster connections to
each other than the net at large, but generally speaking, the main
performance problems of p2p are finding someone else you want, getting
them to offer it for upload, and using your whole net connection. I've
basically chucked working on anything but those three problems for
BitTorrent, and even that's proving to require quite the technical tour de
force to get right.

-Bram Cohen

"Markets can remain irrational longer than you can remain solvent"
-- John Maynard Keynes


---
You are currently subscribed to bluesky as: josh AT mercuryfs.net
For list information visit http://www.transarc.ibm.com/~ota/bluesky/





Archive powered by MHonArc 2.6.24.

Top of Page