public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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: Fri, 5 Nov 2010 22:07:21 -0700	[thread overview]
Message-ID: <20101106050721.GA2194@kroah.com> (raw)
In-Reply-To: <AANLkTinOeby9P847gJFn_t0h5nDY7cfi3cW9hEaUrS1v@mail.gmail.com>

On Fri, Nov 05, 2010 at 04:09:31PM -0700, Yehuda Sadeh Weinraub wrote:
> The rbd module that was recently merged into the linux kernel on the
> 2.6.37-rc1 merge window is based on the osdblk device driver. Other
> than being somewhat confusing (as in ceph we use the term osd too) it
> had been a valuable resource and jump started the development effort.
> One thing that we inherited from osdblk is the sysfs class interface
> that was used there. Generally, there is a single flat class control
> directory that allows adding, removing and listing of devices. For rbd
> we expanded this interface to include all snapshots operations too.
> This, however, might not be completely suitable to rbd. First, there
> might be many different devices, so that having a single control for
> all is cumbersome. The problem is exacerbated with rbd snapshots, as
> there can be many snapshots to a single device, so using a single
> control for all devices and snapshots doesn't scale.
> 
> Another point to consider is the integration with udev, so that
> devices can be created and mapped automaticallty to /dev.
> We'd like to replace the current rbd class interface, and if possible
> to make it asap, so that the current interfaces won't be set in stone
> once 2.6.37 is out. At this point we wanted to do something like the
> following:
> 
> Under /sys/class/rbd there'd we'll keep the 'add' entry that adds rbd devices:
> 
>  # echo "10.0.0.1 name=admin rbd myimage" > /sys/class/rbd/add
> 
> The devices that'll be created still be enumerated, and there'll be a
> subdirectory under rbd/ for each (actually a soft link to
> /sys/devices/virtual/rbd/<id>). For each device we'll have multiple
> read-only properties (name, pool, size, client_id, major, cur_snap,
> snapshots) and a few control entries that'll allow controlling it
> (e.g., remove, refresh, snap_create, snap_rollback).
> 
> We're not sure whether the available snapshots go under the device
> (e.g., rbd/<id>/snaps/...) or just keep it on a single 'snapshots'
> entry.
> 
> 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?

thanks,

greg k-h

  reply	other threads:[~2010-11-06  5: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 [this message]
2010-11-06  5:51   ` Yehuda Sadeh Weinraub
2010-11-10 19:21     ` Yehuda Sadeh Weinraub
2010-11-11  1:08       ` Greg KH
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=20101106050721.GA2194@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