[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080830185613.GC12546@glandium.org>
Date: Sat, 30 Aug 2008 20:56:13 +0200
From: Mike Hommey <mh@...ndium.org>
To: Tejun Heo <tj@...nel.org>
Cc: Archie Cobbs <archie@...lroad.org>,
fuse-devel@...ts.sourceforge.net, miklos@...redi.hu,
linux-kernel@...r.kernel.org, greg@...ah.com
Subject: Re: [fuse-devel] [PATCHSET] CUSE: implement CUSE
On Sat, Aug 30, 2008 at 02:30:32PM +0200, Tejun Heo wrote:
> Hello,
>
> Archie Cobbs wrote:
> >> Thought about that but it's really no different from nbd or loop
> >> depending on your application and block devices don't really implement
> >> the file operations so it won't have too much in common with FUSE.
> >
> > I think BUSE would be useful. For one, it allows you to avoid problems with
> > the extra caching you get with a loopback device. And NBD is too limiting
> > for some applications.
> >
> > For my half-ignorant analysis of the caching issues, see:
> > http://code.google.com/p/s3backer/wiki/PerformanceConsiderations#Caching
> >
> > This is also an example of an application where NBD doesn't suffice.
> >
> >> Also, there's the complication of going out to disk for more memory cases.
> >
> > Not sure what you mean exactly (my fault), but it seems BUSE would have fewer
> > places for memory problems (including deadlocks) than loopback over FUSE,
> > which is the only way to do this kind of stuff now.
>
> Yeah, compared to loopback over FUSE, anything would have less
> problem. :-) I don't know much about nbd but it's pretty much solving
> the same problem so I think it's logical to extend nbd including
> giving it a new transport if necessary? Or is there something
> fundamentally better when it's done via FUSE?
My gutt feeling is that it would have less overhead when done via FUSE
than through nbd, but that could be wrong.
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists