Skip to Content.
Sympa Menu

bluesky - RE: 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>
  • Subject: RE: the mercury file system
  • Date: Mon, 30 Jul 2001 20:55:15 -0700


Well.... The design is public. Perhaps you should read it, and respond in a
technical way.

-----Original Message-----
From: Dan Moniz [mailto:dnm AT pobox.com]
Sent: Monday, July 30, 2001 8:49 PM
To: Global-Scale Distributed Storage Systems
Subject: Re: the mercury file system

I've avoided posting on this thread here because I was waiting for
Bram to get to it. Hi Bram!

>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.

I don't mean to rain on anyone's parade here, and please excuse me
for thinking like an engineer in the next few points:

Assuming I bought all the rhetoric, which seems vapid and more like a
press release than a technical clarification, what makes you
different, at least in the abstract, from SFS <http://fs.net/>, or
like Wesley asked, OceanStore <http://oceanstore.cs.berkeley.edu/>?
I'd like to see some point by point technical comparisons. It ought
to be easy with OceanStore because you wouldn't have to pony up any
code, just design points that explicitly show the differences.

I could get into all I see wrong with the string of comments starting
with "With MFS if you were to map a drive letter to the office, via a
modem, [...] it will be slow the first time only [...] makes a lot of
other features possible [...].", but I don't really think I need to.

>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.

Huh? What? Come again?

You see speed as being the main barrier to a global filesystem that
people access over the Internet (or a modem as well, if I'm
interpreting the text above correctly)?

You think the system will be adopted due to some fictional amount of
functionality, itself something I would generously call "confused"?

And you think that Java can handle "the rest"?

Maybe I'm the bigger idiot for biting the bait being trolled past me,
but in honestly, I'd really like to find out what the hell is going
on . I don't see anything worth looking at here, and I'm not
convinced you've done any amount of homework.

>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,

"It accesses a file by it's data, using a formula that can be
extracted from the data and URL"? How do other filesystems access
files in comparison to MFS? Furthermore (see below)....

>the provider is irrelevant. Security, the MFS hierarchy, and time do not

How does this revolutionary method make the provide irrelevant?
Wasn't I just using a modem to run Microsoft Office off of a server
and then magically getting some other amazing speed benefits? What's
this talk of providers?

>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.

Where? If I somehow use a formula that's extracted from the data and
the URL to access a file by it's data (huh?), where would MFS handles
matter? Furthermore, what exactly is the pseudoscientific premise
behind all of this?

I hope you understand that this sounds like a lot of crap. Seriously.
I keep hoping there's a real idea here, but so far, everything seems
disjointed, with no real detail, with no outward indication that
you've studied any of the other systems you claim to be better than.

>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

Hybrid systems are something I have significant experience with.
Please do explain, in detail, how you maintain linear scalability of
resources in your hybrid model. I'd like to see some math backing
your story before I buy this.

>of peer to peer because the servers are not the bottleneck, unlike
>client/server. With location independence, if a server is busy it will

But a server would have to be a bottleneck if it's a hybrid system.
It may not be a critical bottleneck, but again, at this point, I
think I'm constructing in my head way more than you have actually
thought out and had validated by people who know what they're doing.

>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)

Run on anything how? Java? How does this solve the issues of
presenting me with a native Windows file share, like you mention way
at the top (y'know, over a modem line, et alia)?

Wow. This is obtuse. It can emulate all the other what? Filesystems?
P2P systems? Databases? Bass-o-Matics?

I'm still hungry for real meat.


--
Dan Moniz <dnm AT pobox.com> [http://www.pobox.com/~dnm/]

---
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