Date: Wed, 28 Mar 2007 08:29:49 -0400 From: Greg Troxel <gdt@ir.bbn.com> To: Ivan Voras <ivoras@fer.hr> Cc: freebsd-fs@freebsd.org Subject: Re: TDFS ... or other distributed file system technologies for FreeBSD? Message-ID: <rmi7it11rgi.fsf@fnord.ir.bbn.com> In-Reply-To: <eubmlt$fgp$1@sea.gmane.org> (Ivan Voras's message of "Tue\, 27 Mar 2007 20\:10\:05 %2B0200") References: <4746DA006C148BC0FF1241C6@ganymede.hub.org> <euberg$f1u$1@sea.gmane.org> <45CCECCB7ECB612F504211F3@ganymede.hub.org> <eubmlt$fgp$1@sea.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-=-=
Ivan Voras <ivoras@fer.hr> writes:
> Marc G. Fournier wrote:
>
>> I'm just wondering if it would be time better spent polishing off
>> the FUSE implementation and pushing that for now, get ppl deploying
>> it, testing it, etc ... and then work on the 'performance enhanced
>> kernel module'?
>
> If time to deployment is in question, TDFS is the way to go, and this
> would be what I prefer. Another idea of mine for this is that maybe they
> could be made compatible in the network protocol... lots of ideas,
> little time.
I've been playing with Coda for a long time, originally in FreeBSD
2.2, 3 and 4, and more recently in NetBSD. My problems have been all
correctness issues, both in coda's handling of conflicts and in the
kernel vfs locking code. Coda has not yet worked reliably enough that
I've been worried about performance. Once you put a network and
another system in the path, the round trip to user space is not that
big a deal.
It is truly hard to get the vfs locking issues right (lock one vnode,
release another, do it in the right order, reference counts, follow
the rules exactly). FUSE should (and probably is) taking care of this
for you.
So, I'd go for FUSE, and I think it will be a long time before
performance is a big issue.
>> Then again, from the other side of the coin ... what are the
>> chances that a kernel module would get into the main stream
>> distribution vs the FUSE module?
>
> Since FUSE is (L)GPL'ed, chances of getting it into base are
> slim. Then there's the question of who would be responsible for it,
> since the developer of the FUSE BSD module was also a SoC student
> and I don't know if he's interested in maintaining it that way -
> I'll go ask him.
The other thing people could do is import puffs and librefuse from
NetBSD (also originally an SoC project). puffs is like FUSE, but aims
to be a richer interface. librefuse uses puffs to provide a
FUSE-compatible interface, so you can run FUSE filesystems linked
against librefuse, and there's no GPL/LGPL code in the base system.
puffs is not yet mature; it's not even included in the build of
NetBSD-current unless you put MKPUFF=yes in mk.conf. But I've run a
puffs ssh filesystem under it, and a FUSE http filesystem, and it's
mostly stable.
Porting it to FreeBSD should mostly be straightforward, but I think
the VFS locking rules have diverged, particularly in how .. locking is
handled in vfs_lookup. So making puffs work in FreeBSD will require
cycles from someone who groks the vfs layer.
PUFFS(3) NetBSD Library Functions Manual PUFFS(3)
NAME
libpuffs -- Pass-to-Userspace Framework File System development interface
--=-=-=
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)
iD8DBQFGCl+9+vesoDJhHiURAoIkAKCN5/RTDgTMBdaODSwRwDzAL2b8XgCfduOr
TGOgoNXfMmJa+77DTl3wjy4=
=ZznB
-----END PGP SIGNATURE-----
--=-=-=--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?rmi7it11rgi.fsf>