linux-kernel - [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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <AANLkTinOeby9P847gJFn_t0h5nDY7cfi3cW9hEaUrS1v@mail.gmail.com>
Date:	Fri, 5 Nov 2010 16:09:31 -0700
From:	Yehuda Sadeh Weinraub <yehudasa@...il.com>
To:	ceph-devel@...r.kernel.org
Cc:	Sage Weil <sage@...dream.net>, Greg KH <greg@...ah.com>,
	linux-kernel@...r.kernel.org
Subject: [RFC] rbd sysfs interface

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.

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/