public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Sage Weil <sage@newdream.net>
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:56:56 -0800	[thread overview]
Message-ID: <20101123005656.GA29289@kroah.com> (raw)
In-Reply-To: <Pine.LNX.4.64.1011221626430.18814@cobra.newdream.net>

On Mon, Nov 22, 2010 at 04:45:31PM -0800, Sage Weil wrote:
> 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!  

How about:
	4- make the code depend on CONFIG_BROKEN and get it working for
	.38?

thanks,

greg k-h

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

Thread overview: 21+ 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-18  1:30     ` Greg KH
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-23  0:14             ` Greg KH
2010-11-23  0:48               ` Yehuda Sadeh Weinraub
2010-11-23  0:58                 ` Greg KH
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
2010-11-23  0:56                 ` Greg KH [this message]

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=20101123005656.GA29289@kroah.com \
    --to=greg@kroah.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sage@newdream.net \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox