| Message ID | 1340964038-32584-1-git-send-email-liubo2009@cn.fujitsu.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, Jun 29, 2012 at 06:00:36PM +0800, Liu Bo wrote: > Setting subvolume/snapshot readonly has been missing for a long time. > > With this patch, we can set a subvolume/snapshot readonly via: > > o btrfs subvolume set-ro <path> Alexander's 'btrfs property' patches do exactly this, but in a much more generic and extensible way. 'btrfs property' subgroup provides a uniform interface for getting and setting properties of filesystem objects in general, not only those of subvolumes and snapshots. It provides a much better user interface, and it also allows us to easily rethink kernel-user interface for generic get/set in future. Thanks, Ilya -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 06/29/2012 06:21 PM, Ilya Dryomov wrote: > On Fri, Jun 29, 2012 at 06:00:36PM +0800, Liu Bo wrote: >> Setting subvolume/snapshot readonly has been missing for a long time. >> >> With this patch, we can set a subvolume/snapshot readonly via: >> >> o btrfs subvolume set-ro <path> > > Alexander's 'btrfs property' patches do exactly this, but in a much more > generic and extensible way. 'btrfs property' subgroup provides a > uniform interface for getting and setting properties of filesystem > objects in general, not only those of subvolumes and snapshots. It > provides a much better user interface, and it also allows us to easily > rethink kernel-user interface for generic get/set in future. > Thanks for the explanation! But I prefer keeping the current categories {subvolume,filesystem,device,...}: o Compatibility, we cannot remove the old commands until we make sure that no users will use them. o We've three properties {default, readonly, lable}, is it worthy making another new interface? o Current categories are clear and clean. thanks, liubo > Thanks, > > Ilya > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jul 02, 2012 at 10:07:42AM +0800, Liu Bo wrote: > On 06/29/2012 06:21 PM, Ilya Dryomov wrote: > > > On Fri, Jun 29, 2012 at 06:00:36PM +0800, Liu Bo wrote: > >> Setting subvolume/snapshot readonly has been missing for a long time. > >> > >> With this patch, we can set a subvolume/snapshot readonly via: > >> > >> o btrfs subvolume set-ro <path> > > > > Alexander's 'btrfs property' patches do exactly this, but in a much more > > generic and extensible way. 'btrfs property' subgroup provides a > > uniform interface for getting and setting properties of filesystem > > objects in general, not only those of subvolumes and snapshots. It > > provides a much better user interface, and it also allows us to easily > > rethink kernel-user interface for generic get/set in future. > > > > > Thanks for the explanation! > > But I prefer keeping the current categories {subvolume,filesystem,device,...}: > > o Compatibility, we cannot remove the old commands until we make sure that no users will > use them. We are not going to remove old commands any time soon. However, adding new ones that clearly fall into get/set category, is not a good idea. Especially when there is a generic interface on its way. > > o We've three properties {default, readonly, lable}, is it worthy making another new interface? It's not just about subvolumes. There will be a lot more properties on the table as filesystem matures, for example device speeds, subvolume profiles, quotas. > > o Current categories are clear and clean. Once again, it's not just about subvolumes. Current categories are indeed clear, but adding two commands for each non-trivial property that comes up in future does not seem practical to me. Thanks, Ilya -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/02/2012 06:00 PM, Ilya Dryomov wrote: > On Mon, Jul 02, 2012 at 10:07:42AM +0800, Liu Bo wrote: >> On 06/29/2012 06:21 PM, Ilya Dryomov wrote: >> >>> On Fri, Jun 29, 2012 at 06:00:36PM +0800, Liu Bo wrote: >>>> Setting subvolume/snapshot readonly has been missing for a long time. >>>> >>>> With this patch, we can set a subvolume/snapshot readonly via: >>>> >>>> o btrfs subvolume set-ro <path> >>> Alexander's 'btrfs property' patches do exactly this, but in a much more >>> generic and extensible way. 'btrfs property' subgroup provides a >>> uniform interface for getting and setting properties of filesystem >>> objects in general, not only those of subvolumes and snapshots. It >>> provides a much better user interface, and it also allows us to easily >>> rethink kernel-user interface for generic get/set in future. >>> >> >> Thanks for the explanation! >> >> But I prefer keeping the current categories {subvolume,filesystem,device,...}: >> >> o Compatibility, we cannot remove the old commands until we make sure that no users will >> use them. > > We are not going to remove old commands any time soon. However, adding > new ones that clearly fall into get/set category, is not a good idea. > Especially when there is a generic interface on its way. > >> o We've three properties {default, readonly, lable}, is it worthy making another new interface? > > It's not just about subvolumes. There will be a lot more properties on > the table as filesystem matures, for example device speeds, subvolume > profiles, quotas. > >> o Current categories are clear and clean. > > Once again, it's not just about subvolumes. Current categories are > indeed clear, but adding two commands for each non-trivial property that > comes up in future does not seem practical to me. > I see, that's reasonable. :) Besides set/get-ro and get-default, I also want to have 'btrfs subvolume list' work as 'ls', that is, it can list not only all of items, but also a single item. And I have made a patch for that (it refers to [PATCH 3/3] Btrfs-progs: add 's' option for 'btrfs subvolume list'). What's your opinion about it? thanks, liubo > Thanks, > > Ilya > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/cmds-subvolume.c b/cmds-subvolume.c index 950fa8f..5ee31cb 100644 --- a/cmds-subvolume.c +++ b/cmds-subvolume.c @@ -512,6 +512,44 @@ static int cmd_find_new(int argc, char **argv) return 0; } +static const char * const cmd_subvol_set_ro_usage[] = { + "btrfs subvolume set-ro <path>", + "Set the subvolume ro", + NULL +}; + +static int cmd_subvol_set_ro(int argc, char **argv) +{ + int ret=0, fd, e; + char *path; + struct btrfs_ioctl_get_set_flags_args args; + + if (check_argc_exact(argc, 2)) + usage(cmd_subvol_set_ro_usage); + + path = argv[1]; + + memset(&args, 0, sizeof(args)); + + fd = open_file_or_dir(path); + if (fd < 0) { + fprintf(stderr, "ERROR: can't access to '%s'\n", path); + return 12; + } + + args.flags |= BTRFS_SUBVOL_RDONLY; + args.objectid = 0; + ret = ioctl(fd, BTRFS_IOC_SUBVOL_SETFLAGS, &args); + e = errno; + close(fd); + if( ret < 0 ){ + fprintf(stderr, "ERROR: unable to set a subvolume RO- %s\n", + strerror(e)); + return 30; + } + return 0; +} + const struct cmd_group subvolume_cmd_group = { subvolume_cmd_group_usage, NULL, { { "create", cmd_subvol_create, cmd_subvol_create_usage, NULL, 0 }, @@ -522,6 +560,8 @@ const struct cmd_group subvolume_cmd_group = { cmd_subvol_get_default_usage, NULL, 0 }, { "set-default", cmd_subvol_set_default, cmd_subvol_set_default_usage, NULL, 0 }, + { "set-ro", cmd_subvol_set_ro, + cmd_subvol_set_ro_usage, NULL, 0 }, { "find-new", cmd_find_new, cmd_find_new_usage, NULL, 0 }, { 0, 0, 0, 0, 0 } } diff --git a/ioctl.h b/ioctl.h index f2e5d8d..9c066eb 100644 --- a/ioctl.h +++ b/ioctl.h @@ -42,6 +42,11 @@ struct btrfs_ioctl_vol_args_v2 { char name[BTRFS_SUBVOL_NAME_MAX + 1]; }; +struct btrfs_ioctl_get_set_flags_args { + __u64 objectid; + __u64 flags; +}; + #define BTRFS_FSID_SIZE 16 #define BTRFS_UUID_SIZE 16 @@ -312,6 +317,8 @@ struct btrfs_ioctl_logical_ino_args { struct btrfs_ioctl_space_args) #define BTRFS_IOC_SNAP_CREATE_V2 _IOW(BTRFS_IOCTL_MAGIC, 23, \ struct btrfs_ioctl_vol_args_v2) +#define BTRFS_IOC_SUBVOL_GETFLAGS _IOW(BTRFS_IOCTL_MAGIC, 25, __u64) +#define BTRFS_IOC_SUBVOL_SETFLAGS _IOW(BTRFS_IOCTL_MAGIC, 26, __u64) #define BTRFS_IOC_SCRUB _IOWR(BTRFS_IOCTL_MAGIC, 27, \ struct btrfs_ioctl_scrub_args) #define BTRFS_IOC_SCRUB_CANCEL _IO(BTRFS_IOCTL_MAGIC, 28)
Setting subvolume/snapshot readonly has been missing for a long time. With this patch, we can set a subvolume/snapshot readonly via: o btrfs subvolume set-ro <path> Signed-off-by: Liu Bo <liubo2009@cn.fujitsu.com> --- cmds-subvolume.c | 40 ++++++++++++++++++++++++++++++++++++++++ ioctl.h | 7 +++++++ 2 files changed, 47 insertions(+), 0 deletions(-)