linux-kernel - Re: [PATCH] rbd: replace the rbd sysfs interface

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 22 Nov 2010 16:45:31 -0800 (PST)
From:	Sage Weil <sage@...dream.net>
To:	Greg KH <greg@...ah.com>
cc:	Yehuda Sadeh <yehuda@...newdream.net>, ceph-devel@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] rbd: replace the rbd sysfs interface

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@...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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/