Date: Fri, 06 Sep 2002 05:07:58 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Seva Tonkonoh <seva3@pacbell.net> Cc: freebsd-hackers@freebsd.org Subject: Re: intermezzo? Message-ID: <3D789A9E.A8E3B54@mindspring.com> References: <HCEFKCPGKNFEEKENEECHIEIMCBAA.seva3@pacbell.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Seva Tonkonoh wrote:
> I have recently come across an old little discussion about InterMezzo.
> I 've got the impression that it wasn't really welcome to FreeBSD.
It's illegal to distribute a binary FreeBSD distribution with
GPL'ed components linked into the kernel because of clause 6 of
the GPL.
As long as the boot FS is not InterMezzo, and the FS is loaded
as a seperately compiled module, there should be no problem with
it.
I kind of wish they'd LGPL'ed it, or figured some other way to
not "poison pill" the code, but it still seems like it could be
used.
> Just curious if something similar has been done for FreeBSD, or if
> someone is working on such thing.
Sarnoff has done a similar implementation for FreeBSD, called
MNFS, which had an integrated distributed cache coherency protocol,
and was implemented for FreeBSD circa 1996.
The InterMezzo paper suggest that we call te driver that implements
this "a cache filter driver"; standard terminaology says we should
call them "oplocks" ("opportunistic locks") or "leases". NFSv3 and
NFSv4 have these features, in increasing order of integration. They
note this in section 3 of their paper, but maintain their use of the
"callback"/"filter driver" terminology. Maybe they wanted a patent.
8-).
InterMezzo also appears to want to disable the local buffer cache,
with regard to involvement in open/close (section 4). Since the
VM and buffer cache are integrated in FreeBSD, this is not really
possible to do. The concentration on "open/close" time is probably
at fault here; you could get the same effect by caching file
handles, where a real close lags some time after a close request,
so that the open can be reacquired without a probem. IMO, though,
this is very much an artifact of the use of Coda, and not a general
optimization applicable to a correctly written distributed FS client.
Some of the benchmarks are pretty bogus in the writeback caching
(section 5). In particular, the mkdir/rmdir "benchmark" is a bit
contrived, compared to real world usage patterns for FS's.
> I am actually looking for an MS research project topic and
> Intermezzo seemed to be an interesting possibility.
> Other suggestions would be also helpful.
You could implement this as a stacking VFS module fairly easily,
beginning with the NULLFS code. The cache coherency issues in
FreeBSD mean that you will be converting get/put page operations
into read/write operations in your FS stacking layer (FreeBSD does
not properly support stacking of all VOP's, at present), but the
performance impact for the microbenchmarks in question should not
really affect your FreeBSD numbers (the microbenchmarks that are
describd in the paper bear little resemblance to "real work", so
things that will hurt the performance of "real work", won't hurt
the results of the microbenchmarks; guess you could say that was
a good thing ;^)).
The paper also doesn't really apply to FreeBSD; the FFS sync issues
that it describes are vs. the NetBSD Coda implementation. The FFS
in FreeBSD overcomes most of these issues via Soft Updates. They
also could have mounted the FS async in NetBSD, to put it on a par
with the speed and reliability of Ext2.
All in all, it looks like an interesting thing to play with, and
since you aren't going to boot from it, it's not prohibitive in
the ability of people to really use the work, like an XFS or JFS
GPL'ed FS that you would use as your root/boot FS would be.
If you need a proof of concept, then you should block diagram out
an implementation, assuming VFS stacking, and see if it can work
that way (IMO, it can, bt I don't know how accurately the diagrams
in the InterMezzo paper represent the interface encapsulation they
imply).
The most important consideration in any MS project is whether or
not the project is interesting to you, and what you can get out
of it (IMO). Whatever you do, do it for yourself, and if it's
useful to anyone else, that's just gravy. 8-).
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D789A9E.A8E3B54>