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]
Date:	Tue, 20 Sep 2011 22:57:09 -0700
From:	Kent Overstreet <kent.overstreet@...il.com>
To:	Pekka Enberg <penberg@...helsinki.fi>
Cc:	linux-bcache@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, rdunlap@...otime.net,
	axboe@...nel.dk, akpm@...ux-foundation.org, neilb@...e.de
Subject: Re: [GIT] Bcache version 12

On Wed, Sep 21, 2011 at 08:42:01AM +0300, Pekka Enberg wrote:
> On Wed, Sep 21, 2011 at 5:55 AM, Kent Overstreet
> > <kent.overstreet@...il.com> wrote:
> >> Short version: bcache is for making IO faster.
> 
> On Wed, Sep 21, 2011 at 8:33 AM, Pekka Enberg <penberg@...helsinki.fi> wrote:
> > That's helpful...
> 
> Your documentation isn't helpful either:
> 
> +Say you've got a big slow raid 6, and an X-25E or three. Wouldn't it be
> +nice if you could use them as cache... Hence bcache.
> 
> So it's a cool hack but you fail to explain why someone wants to use
> it. You also fail to explain why you decided to implement it the way
> you did instead of making it more like fscache, for example.
> 
> Really, why do I need to go digging for this sort of information? It
> feels almost as if you don't want people to review your code...

The documentation should be better and better organized to be sure, but
I'm honestly not sure what's so strange about the concept of a cache for
block devices..

My changelog messages are certainly lousy but they aren't really the
place for a design doc, if that's what you're looking for.

As for bcache's design vs. fscache's design... well, they're so unlike
each other I'm not sure it even makes much sense to go into much.

Bcache caches block devices, fscache caches at the filesystem layer.
They each have uses where the other can't be used.

If you want more than that - IMO bcache's design is simpler, higher
performing, and more flexible.

bcache doesn't have to have a notion of files; it caches extents.

It can cache filesystem metadata - it can cache anything.

Because bcache has its own superblock (much like md), it can guarantee
that bcache devices are consistent; this is particularly important if
you want to do writeback caching. You really don't want to accidently
mount a filesystem that you were doing writeback caching on without the
ache - bcache makes it impossible to do so accidently.

Is any of that useful?
--
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