On Wed, Jun 27, 2012 at 7:41 PM, Goffredo Baroncelli kreij...@libero.it wrote:
Hi Alexander,
On 06/27/2012 03:16 PM, Alexander Block wrote:
This patchset introduces the btrfs property subgroup. It is the
result of a discussion we had on IRC. I tried to make the properties
interface as generic and extensible as possible. Comments are welcome.
Currently the command group looks like this:
btrfs prop set [-t type] /path/to/object name value
btrfs prop get [-t type] /path/to/object [name] (omitting name dumps all)
btrfs prop list [-t type] /path/to/object (lists properties with
description)
The type is used to explicitly specify what type of object you mean. This is
necessary in case the object+property combination is ambiguous. For example
'/path/to/fs/root' could mean the root subvolume, the directory inode or the
filesystem itself. Normally, btrfs-progs will try to detect the type
automatically.
Instead of using
btrfs prop set -t filesystem
btrfs prop set -t subvolume
btrfs prop set -t inode
what about
btrfs filesystem prop set .
btrfs subvolume prop set .
btrfs inode prop set .
?
Specifying the object type is not needed normally, so the form where
the prop commands
are in their own command group is normally shorter and easier to type.
The type argument
is really only needed for ambiguous properties.
btrfs has already grouped the commands by category (even tough I have
to admit that some command doesn't fit its group. Why do not use this
instead of -t object type. If we need new type we could create it on
demand...
David suggested that it should also be possible to specify objects by
their id/uuid/fsid. I like that idea, but would be happy if someone else
could take over that part :)
This proposal makes sense.
For now, I've implemented two properties:
1. read-only. Usable on subvolumes to toggle the read-only flags.
2. label. I looked through btrfs to find good examples of things that
could be moved to the new properties interface and the filesystem
label looked like a good one. There are for sure more, but that is
something for later (and maybe for someone else). I would suggest
to move everthing that makes sense over to the props interface and
mark the old interfaces as deprecated. Comments on this are welcome.
What is the suppose goal/benefit/advantage to switch to a new interface
? Really, it is a true question.
The reason is that there will come a lot more things that you can
configure on an
inode/subvolume/filesystem/device basis and we agreed that a generic interface
for such configurations will be a good thing in the future.
Patch version history:
v1
Initial version.
v2
- Removed the filesystem prefix and implemented it as new command group
- Switched from the name[=value] form to the set/get name [value]
form.
- Removed patches Btrfs-progs: make filesystem_cmd_group non const
and Btrfs-progs: move skip_prefix and prefixcmp to utils.c. They
are not needed anymore due to the 'btrfs prop list' command.
- Udjusted the subvol flags patch to be compatible to the Btrfs: use
_IOR for BTRFS_IOC_SUBVOL_GETFLAGS patch.
- Using -t type instead of type: prefix now.
- Changes are based on feedback from Ilya and David.
Alex.
Alexander Block (3):
Btrfs-progs: add BTRFS_IOC_SUBVOL_GET/SETFLAGS to ioctl.h
Btrfs-progs: let get_label return the label instead of of printing it
Btrfs-progs: introduce btrfs property subgroup
Makefile | 5 +-
btrfs.c | 1 +
btrfslabel.c | 13 +-
btrfslabel.h | 4 +-
cmds-filesystem.c | 14 +-
cmds-property.c | 459
+
commands.h | 2 +
ioctl.h | 2 +
props.c | 114 +
props.h | 43 +
Please update the man page too... This could help the process of
creating a new interface.
10 files changed, 645 insertions(+), 12 deletions(-)
create mode 100644 cmds-property.c
create mode 100644 props.c
create mode 100644 props.h
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html