From: Kent Overstreet <kent.overstreet@gmail.com>
To: Greg KH <greg@kroah.com>
Cc: linux-bcache@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Subject: Re: Bcache version 9
Date: Tue, 23 Nov 2010 00:07:36 -0800 [thread overview]
Message-ID: <4CEB7648.8030000@gmail.com> (raw)
In-Reply-To: <20101122010914.GB7688@kroah.com>
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
> 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.
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. 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...
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.
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 :)
next prev parent reply other threads:[~2010-11-23 8:07 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-21 14:09 Bcache version 9 Kent Overstreet
2010-11-22 1:09 ` Greg KH
2010-11-23 8:07 ` Kent Overstreet [this message]
[not found] ` <4CEB7648.8030000-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2010-12-01 4:16 ` Greg KH
2010-12-01 4:16 ` Greg KH
[not found] ` <20101201041610.GA5891-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2010-12-04 3:24 ` Kent Overstreet
2010-12-04 3:24 ` Kent Overstreet
2010-12-04 3:24 ` Kent Overstreet
2010-12-16 11:21 ` Kent Overstreet
2010-12-16 11:21 ` Kent Overstreet
2010-11-23 23:35 ` Cédric Villemain
2010-11-23 23:35 ` Cédric Villemain
2010-11-24 6:25 ` Kent Overstreet
[not found] ` <4CECAFD1.10506-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2010-12-04 5:41 ` John Drescher
2010-12-04 5:41 ` John Drescher
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CEB7648.8030000@gmail.com \
--to=kent.overstreet@gmail.com \
--cc=greg@kroah.com \
--cc=linux-bcache@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.