Re: Bcache version 9

Re: Bcache version 9

[Greg KH]

On Tue, Nov 23, 2010 at 12:07:36AM -0800, Kent Overstreet wrote:
> On 11/21/2010 05:09 PM, Greg KH wrote:
> >On Sun, Nov 21, 2010 at 06:09:34AM -0800, Kent Overstreet wrote:
> >>+++ b/Documentation/bcache.txt
> >
> >For new sysfs files, please create Documentation/ABI files.
> >
> >>+All configuration is done via sysfs. To use sde to cache md1, assuming the
> >>+SSD's erase block size is 128k:
> >>+
> >>+  make-bcache -b128k /dev/sde
> >>+  echo "/dev/sde">  /sys/kernel/bcache/register_cache
> >>+  echo "<UUID>  /dev/md1">  /sys/kernel/bcache/register_dev
> >
> >/sys/kernel/bcache/?  Really?
> 
> That was a completely arbitrary choice dating from when I first
> started hacking on it. No point in moving it when it might be moved
> again :p

Heh.

> >Come on, shouldn't this be somewhere else?  You only have 1 file here,
> >right?
> 
> Two files (really three, but the third is for gimpy latency tracing
> and will die eventually). register_dev is there so on bootup you
> don't have to wait for the cache to be discovered - when you add a
> cache device if there's a backing device waiting for a cache, and
> the cache has seen that UUID before it'll do what you want.
> 
> >Shouldn't it be a configfs file instead as that is what you are doing?
> 
> That was one of the possibilities I had in mind. My main issue with
> that though is I don't see any way to just have a bare config_item -
> per the documentation, the user must do a mkdir() first, which just
> doesn't make any sense for bcache. There's no point in having a
> persistent object besides the one associated with the block device.
> Maybe there would be in the future, with multiple cache devices, but
> I still think it's a lousy interface for that problem - what bcache
> wants is something more like a syscall; you wouldn't use configfs to
> replace mount(), for example.

True, but I thought configfs could handle "bare" config items, you might
want to look a bit closer as to how people are using it.  But I could be
totally wrong however.

> There do exist global interfaces in sysfs, not attached to any
> device - besides /sys/kernel, there's /sys/fs which doesn't have any
> rhyme or reason to it I can discern.

/sys/fs is for different filesystem specific things.

> ecryptfs has
> /sys/ext4/ecryptfs/version, ext4 has per device stuff that you can't
> find from the device's dir (you woludn't know /sys/fs/ext4/md0
> exists from looking at /sys/block/md0). There's also /sys/fs/cgroup,
> which is another unique thing as far as I can tell...

No, sys/fs/cgroup/ is where the cgroup filesystem is mounted.

> Then there's /sys/module which has a bunch of ad hoc stuff, but as
> far as I can tell that's all still module parameters and
> register_cache and register_dev certainly aren't module parameters.

It's not ad hoc, it's module specific things.

> So anyways, I absolutely agree that there are better solutions than
> /sys/kernel/bcache but I want to replace it with something correct,
> not something that sucks less. Ideas/flames are of course more than
> welcome :)

What is "bcache"?  Is it related to filesystems?  If so, use
/sys/fs/bcache and I have no issues with it.  But don't put it in
/sys/kernel/ without at least asking.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bcache version 9

[Kent Overstreet]

On 11/30/2010 08:16 PM, Greg KH wrote:
> True, but I thought configfs could handle "bare" config items, you might
> want to look a bit closer as to how people are using it.  But I could be
> totally wrong however.

The documentation is pretty specific and I haven't seen any 
counterexamples, but I'll see what I can find.

>> There do exist global interfaces in sysfs, not attached to any
>> device - besides /sys/kernel, there's /sys/fs which doesn't have any
>> rhyme or reason to it I can discern.
>
> /sys/fs is for different filesystem specific things.
>
>> ecryptfs has
>> /sys/ext4/ecryptfs/version, ext4 has per device stuff that you can't
>> find from the device's dir (you woludn't know /sys/fs/ext4/md0
>> exists from looking at /sys/block/md0). There's also /sys/fs/cgroup,
>> which is another unique thing as far as I can tell...
>
> No, sys/fs/cgroup/ is where the cgroup filesystem is mounted.

Yes, but as far as how the namespace is used it's exactly the same. By 
that logic, I could stick anything in /sys/fs if I made a filesystem for 
it to mount there. cgroupfs is just an interface, users wouldn't care if 
the same interface was written against sysfs (except for mounting 
multiple instances, but that's still not an argument for putting a 
mountpoint in /sys/fs).

>> Then there's /sys/module which has a bunch of ad hoc stuff, but as
>> far as I can tell that's all still module parameters and
>> register_cache and register_dev certainly aren't module parameters.
>
> It's not ad hoc, it's module specific things.

Exactly :p Bcache lives in a module, as does most code. There's no 
pattern to it besides that, is all I was saying.

> What is "bcache"?  Is it related to filesystems?

It uses SSDs to cache block devices; you'd cache say /dev/md0 with 
/dev/sdb, reads and writes get added to the cache and writes get 
buffered in the cache if writeback caching is on.

> If so, use
> /sys/fs/bcache and I have no issues with it.  But don't put it in
> /sys/kernel/ without at least asking.

You could say it's related to filesystems, but it's an awful stretch 
since it lives entirely at the block layer.

It's on the list of things that need fixing before merging, but that's a 
solid list. Priority #1 has been making it rock solid, which appears to 
be done... I've still got to finish handling all the potential memory 
allocation failures correctly and do something about the hooks in the 
block layer, which is a much bigger problem. I prefer my hacks to be 
obvious, ugly hacks :)


--
To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bcache version 9

[Kent Overstreet]

On 11/30/2010 08:16 PM, Greg KH wrote:
> True, but I thought configfs could handle "bare" config items, you might
> want to look a bit closer as to how people are using it.  But I could be
> totally wrong however.

Just in case I wasn't the only one confused, I stared at the 
documentation and examples some more... still wasn't completely sure, so 
I wrote the code, and bare attributes without a configfs item do work. I 
just switched to configfs for the stuff that was in /sys/kernel/bcache, 
it'll be in the next version.

Almost got everything done on my todo list before it's ready to be 
submitted...

Re: Bcache version 9

[John Drescher]

>> Is it its main diff with flashcache ?
>> https://github.com/facebook/flashcache/blob/master/doc/flashcache-doc.txt
>
> Yeah. It's a more complex approach, but it's capable of significantly higher
> performance. Performance has regressed some lately (I've been concentrating
> on other things and don't really have the hardware for performance work),
> but a month or so ago it was benchmarking around 50% higher than flashcache,
> with mysql on an X25-E.

BTW, Thanks for releasing this..
I am just in the middle of evaluating using flashcache to speed up
slow IO in kvm clients when storing the VMs on hard disks. I will when
I get a chance try your patch..

John
--
To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html