[ATTEND]

[ATTEND]

[Kent Overstreet]

I'm the author of bcache - a flash caching implementation for block
devices. I'd like to talk a bit about it and some
cleanups/improvements to the block layer.

Re: [ATTEND]

[Hannes Reinecke]

On 02/02/2012 10:03 AM, Kent Overstreet wrote:
> I'm the author of bcache - a flash caching implementation for block
> devices. I'd like to talk a bit about it and some
> cleanups/improvements to the block layer.
Hey, cool, then we can do a match which implementation is better :-)

Reminder to self: send dm-ssdcache upstream ...

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ATTEND]

[Kent Overstreet]

Yeah, we can certainly compare notes.

Where's your code at? I've got a git repo up at
http://evilpiepirate.org/git/linux-bcache.git/

On Thu, Feb 2, 2012 at 2:16 AM, Hannes Reinecke <hare@suse.de> wrote:
> On 02/02/2012 10:03 AM, Kent Overstreet wrote:
>> I'm the author of bcache - a flash caching implementation for block
>> devices. I'd like to talk a bit about it and some
>> cleanups/improvements to the block layer.
> Hey, cool, then we can do a match which implementation is better :-)
>
> Reminder to self: send dm-ssdcache upstream ...
>
> Cheers,
>
> Hannes
> --
> Dr. Hannes Reinecke                   zSeries & Storage
> hare@suse.de                          +49 911 74053 688
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
> GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [ATTEND]

[Loke, Chetan]

> -----Original Message-----
> From: linux-scsi-owner@vger.kernel.org [mailto:linux-scsi-
> owner@vger.kernel.org] On Behalf Of Kent Overstreet
> Sent: February 02, 2012 4:04 AM
> To: lsf-pc@lists.linux-foundation.org
> Cc: linux-scsi@vger.kernel.org; linux-fsdevel@vger.kernel.org
> Subject: [ATTEND]
> 
> I'm the author of bcache - a flash caching implementation for block
> devices. I'd like to talk a bit about it and some
> cleanups/improvements to the block layer.

Kent,

I came across UBIFS when I was looking to implement just a backing
device. So I'm trying to understand if you looked at UBIFS and if parts
of that could have been used(or if they are used already?). Because in
the end we need to create an erase-aware FS(without the usual
defrag/syscall/etc support) and manage that in conjunction with
block-layer. Agreed that UBIFS is a generic FS. But we also need to
worry about erase-cycles/counters etc
(http://lxr.linux.no/#linux+v3.2.5/Documentation/filesystems/ubifs.txt#L
12 - all the 5 points). Plus, it supports on-the-fly compression. I've
never used UBIFS. So I don't know how it performs. May be we could just
pick UBI's FS part and stick that with your block-layer code?

CC'd Artem (found his email from sys-abi file).


Chetan Loke

Re: [ATTEND]

[Kent Overstreet]

On Tue, Feb 7, 2012 at 3:31 PM, Loke, Chetan <Chetan.Loke@netscout.com> wrote:
> I came across UBIFS when I was looking to implement just a backing
> device. So I'm trying to understand if you looked at UBIFS and if parts
> of that could have been used(or if they are used already?). Because in
> the end we need to create an erase-aware FS(without the usual
> defrag/syscall/etc support) and manage that in conjunction with
> block-layer. Agreed that UBIFS is a generic FS. But we also need to
> worry about erase-cycles/counters etc
> (http://lxr.linux.no/#linux+v3.2.5/Documentation/filesystems/ubifs.txt#L
> 12 - all the 5 points). Plus, it supports on-the-fly compression. I've
> never used UBIFS. So I don't know how it performs. May be we could just
> pick UBI's FS part and stick that with your block-layer code?

I don't quite follow what you're trying to do - you want to turn raw
flash into a block device, i.e. an ftl?

Bcache is pretty close to being an ftl, and I think what's left will
get finished off sooner or later (I recently implemented flash only
volume support, it works and it's fast but I haven't implemented the
copying garbage collector yet so internal fragmentation limits its
usefulness. It's basically a thin provisioning volume manager for
flash, though).

As far as using bcache for the bottom of a real filesystem - I
definitely want to do that. I haven't looked at ubifs at all; I was
thinking exofs might be a decent starting point, ubifs hadn't crossed
my mind.

There's a bunch of fun things we could do with it, though. After
multiple cache device support is done (there's not much left - it's
just been at the bottom of the todo list) I'm going to write an
allocator more suitable for rotating disks and then it'll do volume
management + thin provisioning + caching, all with the same index. The
btree is outrageously fast now, too - if there's another btree out
there that comes close I'd really like to know.

RE: [ATTEND]

[Loke, Chetan]

> -----Original Message-----
> From: Kent Overstreet [mailto:koverstreet@google.com]
> Sent: February 07, 2012 10:46 PM
> To: Loke, Chetan
> Cc: lsf-pc@lists.linux-foundation.org; linux-scsi@vger.kernel.org;
> linux-fsdevel@vger.kernel.org; dedekind@infradead.org
> Subject: Re: [ATTEND]
> 
> On Tue, Feb 7, 2012 at 3:31 PM, Loke, Chetan
<Chetan.Loke@netscout.com>
> wrote:
> > I came across UBIFS when I was looking to implement just a backing
> > device. So I'm trying to understand if you looked at UBIFS and if
parts
> > of that could have been used(or if they are used already?). Because
in
> > the end we need to create an erase-aware FS(without the usual
> > defrag/syscall/etc support) and manage that in conjunction with
> > block-layer. Agreed that UBIFS is a generic FS. But we also need to
> > worry about erase-cycles/counters etc

.......
> 
> I don't quite follow what you're trying to do - you want to turn raw
> flash into a block device, i.e. an ftl?
> 
> Bcache is pretty close to being an ftl, and I think what's left will

Exactly. So what I'm saying is, if UBI also does ftl then you could be
duplicating code/efforts. UBI is already upstream. Now whether it
supports everything we want is another thing.
(and that's why I CC'd its author). So pieces that aren't there could be
implemented. But they also talk about erase-counters etc and I don't
know if I saw something similar in your bucket_struct[or foo_struct].
May be its somewhere else.

RE: [ATTEND]

[Artem Bityutskiy]

[-- Attachment #1: Type: text/plain, Size: 953 bytes --]

On Wed, 2012-02-08 at 13:15 -0500, Loke, Chetan wrote:
> Exactly. So what I'm saying is, if UBI also does ftl then you could be
> duplicating code/efforts. UBI is already upstream. Now whether it
> supports everything we want is another thing.
> (and that's why I CC'd its author). So pieces that aren't there could be
> implemented. But they also talk about erase-counters etc and I don't
> know if I saw something similar in your bucket_struct[or foo_struct].
> May be its somewhere else.

Hi, UBI is not an FTL, but it implements a lot of things a decent FTL
would also need to implement. And implementing FTL on top of UBI would
be much simpler than on top of a raw flash (I assume you are discussing
a flash?). UBI has it's own strong sides and limitations. Here I
described a simple FTL on top of UBI (long time ago):

http://lists.infradead.org/pipermail/linux-mtd/2008-January/020381.html

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [ATTEND]

[Kent Overstreet]

On Wed, Feb 8, 2012 at 12:20 PM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
> Hi, UBI is not an FTL, but it implements a lot of things a decent FTL
> would also need to implement. And implementing FTL on top of UBI would
> be much simpler than on top of a raw flash (I assume you are discussing
> a flash?). UBI has it's own strong sides and limitations. Here I
> described a simple FTL on top of UBI (long time ago):

You going to be at LSF? Would love to talk to other people with
experience with the gory details of flash :)

Re: [ATTEND]

[Artem Bityutskiy]

[-- Attachment #1: Type: text/plain, Size: 681 bytes --]

On Wed, 2012-02-08 at 12:48 -0800, Kent Overstreet wrote:
> On Wed, Feb 8, 2012 at 12:20 PM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
> > Hi, UBI is not an FTL, but it implements a lot of things a decent FTL
> > would also need to implement. And implementing FTL on top of UBI would
> > be much simpler than on top of a raw flash (I assume you are discussing
> > a flash?). UBI has it's own strong sides and limitations. Here I
> > described a simple FTL on top of UBI (long time ago):
> 
> You going to be at LSF? Would love to talk to other people with
> experience with the gory details of flash :)

Unfortunately no :-(

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [ATTEND]

[Kent Overstreet]

On Wed, Feb 8, 2012 at 10:15 AM, Loke, Chetan <Chetan.Loke@netscout.com> wrote:
> Exactly. So what I'm saying is, if UBI also does ftl then you could be
> duplicating code/efforts. UBI is already upstream. Now whether it
> supports everything we want is another thing.
> (and that's why I CC'd its author). So pieces that aren't there could be
> implemented. But they also talk about erase-counters etc and I don't
> know if I saw something similar in your bucket_struct[or foo_struct].
> May be its somewhere else.

I don't think code sharing is realistic for that stuff, as wear
levelling and all the other flash specific stuff needs to be done in
the same place if you want to avoid having multiple stacked indexes,
and adding wear levelling and a copying garbage collector to bcache is
going to be pretty trivial at this point.

But comparing notes/sharing algorithms could definitely be worthwhile.