From: Greg KH <greg@kroah.com>
To: Yehuda Sadeh Weinraub <yehudasa@gmail.com>
Cc: ceph-devel@vger.kernel.org, Sage Weil <sage@newdream.net>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC] rbd sysfs interface
Date: Wed, 10 Nov 2010 17:08:41 -0800 [thread overview]
Message-ID: <20101111010841.GA23127@kroah.com> (raw)
In-Reply-To: <AANLkTikdr=nJF45QUCKAOY8NSh9GNtv8c9K_oNdJeJfc@mail.gmail.com>
On Wed, Nov 10, 2010 at 11:21:49AM -0800, Yehuda Sadeh Weinraub wrote:
> On Fri, Nov 5, 2010 at 10:51 PM, Yehuda Sadeh Weinraub
> <yehudasa@gmail.com> wrote:
> > On Fri, Nov 5, 2010 at 10:07 PM, Greg KH <greg@kroah.com> wrote:
> >> On Fri, Nov 05, 2010 at 04:09:31PM -0700, Yehuda Sadeh Weinraub wrote:
> >>>
> >>> Does this seem sane? Any comments would be greatly appreciated.
> >>
> >> It sounds like you need to use configfs instead of sysfs, as your model
> >> was the reason it was created.
> >>
> >> Have you tried that?
> >
> > Oh, will look at it now. With ceph (although for a different purpose)
> > we went through proc -> sysfs -> debugfs, however, it seems that we've
> > missed at least one userspace-kernel channel.
> >
>
> Well, we looked a bit at what configfs does, and from what we see it
> doesn't really fit our needs. Configfs would be more suitable to
> configuring a static system than to control a dynamic one. The main
> problem is that items creation is only driven by userspace. That would
> be ok if we had a static mapping of the images and snapshots, however,
> we don't. We need the system to reflect any state change with the
> running configuration (e.g., a new snapshot was created by a different
> client), and it doesn't seem possible with configfs as long as items
> creation is only driven by userspace operations. We need a system that
> would be able to reflect changes that happened due to some external
> operation, and this doesn't seem to be the case here.
>
> There is second issue and that's committable items are not implemented
> there yet. So the interface itself would be a bit weird. E.g., had
> committable items been implemented we would have done something like
> the following:
>
> /config/rbd# mkdir pending/myimage
> /config/rbd# echo foo > pending/myimage/name
> /config/rbd# cat ~/mykey > pending/myimge/key
> /config/rbd# echo 10.0.0.1 > pending/myimage/addr
> ...
> /config/rbd# mv pending/myimage live/
>
> and that would do what we need in terms of initial configuration.
> However, as this is not really implemented yet, there is no
> distinction between images that are pending and images that are live,
> so configuration would look something like:
> /config/rbd# mkdir myimage
> /config/rbd# echo foo > myimage/name
> /config/rbd# cat ~/mykey > myimge/key
> /config/rbd# echo 10.0.0.1 > myimage/addr
> ...
> /config/rbd# echo 1 > myimage/go
>
> And having that, the myimage/ directory will still hold all those
> config options that are moot after the image went live. It doesn't
> seem to offer a significant improvement over the current sysfs one
> liner configuration and with sysfs we can have it reflect any dynamic
> change that occurred within the system. So we tend to opt for an
> improved sysfs solution, similar to the one I described before.
Ok, that makes sense as to why configfs would not work (I really wish
someone would add the commit stuff to configfs, as you aren't the first
ones to want that.)
So, back to sysfs. But I can't recall what your sysfs interface looked
like, do you have Documentation/ABI/ files that show what it does? If
not, you are required to, so you might as well write them now :)
thanks,
greg k-h
next prev parent reply other threads:[~2010-11-11 1:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-05 23:09 [RFC] rbd sysfs interface Yehuda Sadeh Weinraub
2010-11-06 5:07 ` Greg KH
2010-11-06 5:51 ` Yehuda Sadeh Weinraub
2010-11-10 19:21 ` Yehuda Sadeh Weinraub
2010-11-11 1:08 ` Greg KH [this message]
2010-11-11 5:16 ` Yehuda Sadeh Weinraub
2010-11-12 17:49 ` Yehuda Sadeh Weinraub
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=20101111010841.GA23127@kroah.com \
--to=greg@kroah.com \
--cc=ceph-devel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sage@newdream.net \
--cc=yehudasa@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox