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: Dan Moniz <dnm AT pobox.com>
  • To: "Global-Scale Distributed Storage Systems" <bluesky AT franklin.oit.unc.edu>
  • Subject: Re: the mercury file system
  • Date: Mon, 30 Jul 2001 23:49:19 -0400


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




Archive powered by MHonArc 2.6.24.

Top of Page