All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
To: Kent Overstreet
	<kent.overstreet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: linux-bcache-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: Bcache version 9
Date: Tue, 30 Nov 2010 20:16:10 -0800	[thread overview]
Message-ID: <20101201041610.GA5891@kroah.com> (raw)
In-Reply-To: <4CEB7648.8030000-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

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

WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <greg@kroah.com>
To: Kent Overstreet <kent.overstreet@gmail.com>
Cc: linux-bcache@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: Bcache version 9
Date: Tue, 30 Nov 2010 20:16:10 -0800	[thread overview]
Message-ID: <20101201041610.GA5891@kroah.com> (raw)
In-Reply-To: <4CEB7648.8030000@gmail.com>

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

  parent reply	other threads:[~2010-12-01  4:16 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
     [not found]     ` <4CEB7648.8030000-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2010-12-01  4:16       ` Greg KH [this message]
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=20101201041610.GA5891@kroah.com \
    --to=greg-u8xffu+wg4eavxtiumwx3w@public.gmane.org \
    --cc=kent.overstreet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=linux-bcache-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.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.