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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/