All of lore.kernel.org
 help / color / mirror / Atom feed
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 :)

  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.