All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sage Weil <sage@newdream.net>
To: Greg KH <greg@kroah.com>
Cc: Yehuda Sadeh <yehuda@hq.newdream.net>,
	ceph-devel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] rbd: replace the rbd sysfs interface
Date: Mon, 22 Nov 2010 16:45:31 -0800 (PST)	[thread overview]
Message-ID: <Pine.LNX.4.64.1011221626430.18814@cobra.newdream.net> (raw)
In-Reply-To: <20101123001439.GB31294@kroah.com>

Hi Greg,

On Mon, 22 Nov 2010, Greg KH wrote:
> On Mon, Nov 22, 2010 at 03:33:07PM -0800, Yehuda Sadeh wrote:
> > 
> > 
> > On Fri, Nov 19, 2010 at 12:42 PM, Yehuda Sadeh Weinraub <yehuda@hq.newdream.net> wrote:
> > > One solution would be to create kobjects for (3) and for (4), without
> > > using a group name. Another way, we can create groups for (2), and (3)
> > > under (1), but that's about it, you can't create the snap specific
> > > directory this way without resorting to some internal sysfs directory
> > > creation, which will be horribly wrong. At that point we don't have
> > > anything for 'snaps', and we don't really need to do any operations
> > > under that directory, we just need it to exist so that it contains the
> > > snapshot-specific directories.
> > >
> > > Another way would be to create a group for (2) under (1) and create a
> > > kobject for (3), for which you can create group per snapshot.
> > >
> > > Am I missing something? We already have the first solution (kobjects
> > > only) implemented, is there some real benefit for using the third
> > > method? We'll have to manually add remove groups anyway, as snapshots
> > > can be removed and new snapshots can be added.
> > >
> > 
> > And following is the implementation for the first solution. It has a device
> > for the rbd_dev, a kobject for the top snapshot directory and a kobject per
> > snapshot. Please let me know if there's any issue with this implementation.
> > We'd like to get this fixed for 2.6.37 and considering the large patch,
> > it'd be nice getting an ack for it.
> 
> It's way too late for .37, as this is new stuff, right?

Well, that's the problem.  The current sysfs interface was based on 
osdblk's.  That part didn't come up during review, and I wasn't aware that 
the sysfs interface should get an explicit ack from you.  After RBD was 
merged in 2.6.37-rc1 I saw part of the SCST sysfs thread and realized the 
current interface was problematic, and we've been trying to work out how 
to fix it ever since.

As things stand, we can either
 1- wait, get an osdblk-like interface in 2.6.37, and change it later (a 
    big fat no-no, as I understand things!)
 2- get an improved sysfs interface sorted out and push to Linus ASAP (my 
    preference)
 3- have Linus revert RBD altogether :(

I'm hoping for #2, but we may need a bit more help from you unfortunately!  

Basically:
 - We keep putting the <snaps> in a subdir because can be arbitrarily 
named, and we don't want them to collide with the other attributes.  It's 
that or prefixing them with something like "snap_", but that seems uglier.
 - They are only there to expose some information to the user.

Thanks!
sage

  reply	other threads:[~2010-11-23  0:41 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-17  0:32 [PATCH] rbd: replace the rbd sysfs interface Yehuda Sadeh
2010-11-17 17:19 ` Greg KH
2010-11-17 23:00   ` Yehuda Sadeh Weinraub
2010-11-17 23:00     ` Yehuda Sadeh Weinraub
2010-11-18  1:30     ` Greg KH
2010-11-18 22:53       ` Yehuda Sadeh Weinraub
2010-11-18 22:53         ` Yehuda Sadeh Weinraub
2010-11-19  2:08         ` Greg KH
2010-11-19 20:42           ` Yehuda Sadeh Weinraub
2010-11-19 20:42             ` Yehuda Sadeh Weinraub
2010-11-23  0:14             ` Greg KH
2010-11-23  0:14               ` Greg KH
2010-11-23  0:48               ` Yehuda Sadeh Weinraub
2010-11-23  0:48                 ` Yehuda Sadeh Weinraub
2010-11-23  0:58                 ` Greg KH
2010-11-23  0:58                   ` Greg KH
2010-11-23  1:19                   ` Yehuda Sadeh Weinraub
2010-11-23  1:19                     ` Yehuda Sadeh Weinraub
2010-11-24  0:23                   ` Yehuda Sadeh
2010-12-01 19:25                     ` Sage Weil
2010-12-01 19:47                       ` Greg KH
2010-12-01 20:08                         ` Sage Weil
2010-12-01 20:23                           ` Greg KH
2010-12-02  0:11                             ` Sage Weil
2010-11-22 23:33           ` Yehuda Sadeh
2010-11-23  0:14             ` Greg KH
2010-11-23  0:45               ` Sage Weil [this message]
2010-11-23  0:56                 ` Greg KH

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=Pine.LNX.4.64.1011221626430.18814@cobra.newdream.net \
    --to=sage@newdream.net \
    --cc=ceph-devel@vger.kernel.org \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=yehuda@hq.newdream.net \
    /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.