lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ