linux-kernel - Re: [RFC] 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 for Android: free password hash cracker in your pocket

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

Message-ID: <AANLkTi=J4Y5K8wm6PGf+B2F1-CCqX--RWHeS3YbkBP60@mail.gmail.com>
Date:	Fri, 12 Nov 2010 09:49:46 -0800
From:	Yehuda Sadeh Weinraub <yehudasa@...il.com>
To:	Greg KH <greg@...ah.com>
Cc:	ceph-devel@...r.kernel.org, Sage Weil <sage@...dream.net>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC] rbd sysfs interface

On Wed, Nov 10, 2010 at 9:16 PM, Yehuda Sadeh Weinraub
<yehudasa@...il.com> wrote:
> On Wed, Nov 10, 2010 at 5:08 PM, Greg KH <greg@...ah.com> wrote:
>>
>> 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 :)
>>
>
> The original sysfs interface is described in the rbd.c prefix
> comments, which we can copy to Documentation/ABI without much pain.
> However, we were just thinking of modifying it a bit, as described
> previously in my first email. The hierarchy will look like this:
>
> rbd/
>    add
>    remove
>    <id>/
>      name
>      pool
>      size
>      ..
>      snap_add
>      snap_remove
>      snap_rollback
>        <snap_name>/
>          size
>
> The 'add' entry will be used to add a device (as before):
>
>  # 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)
> and a few control entries (e.g., snap_add, snap_remove, etc.)
>
> There will be a subdirectory per snapshot under each device, and all
> the snapshots properties will be kept there.
>

Unless I hear otherwise, I'm going to assume that this proposed
interface is an improvement over the existing osdblk-based one and get
this upstream asap..

Thanks,
Yehuda
--
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/