From: Jeff Mahoney <jeffm@suse.com>
To: dsterba@suse.cz, linux-btrfs@vger.kernel.org, clmason@fusionio.com
Subject: Re: [patch 1/7] [PATCH] btrfs: add ability to query/change feature bits online
Date: Mon, 16 Sep 2013 14:13:11 -0400 [thread overview]
Message-ID: <52374A37.60402@suse.com> (raw)
In-Reply-To: <20130916172651.GV6810@twin.jikos.cz>
[-- Attachment #1: Type: text/plain, Size: 4231 bytes --]
On 9/16/13 1:26 PM, David Sterba wrote:
> On Tue, Sep 10, 2013 at 12:24:09AM -0400, Jeff Mahoney wrote:
>> +static int btrfs_ioctl_set_features(struct file *file, void __user *arg)
>> +{
>> + struct btrfs_root *root = BTRFS_I(file_inode(file))->root;
>> + struct btrfs_super_block *super_block = root->fs_info->super_copy;
>> + struct btrfs_ioctl_feature_flags flags[2];
>> + struct btrfs_trans_handle *trans;
>> + u64 newflags;
>> + int ret;
>> +
>> + if (!capable(CAP_SYS_ADMIN))
>> + return -EPERM;
>> +
>> + if (copy_from_user(flags, arg, sizeof(flags)))
>> + return -EFAULT;
>> +
>> + /* Nothing to do */
>> + if (!flags[0].compat_flags && !flags[0].compat_ro_flags &&
>> + !flags[0].incompat_flags)
>> + return 0;
>> +
>> + ret = check_feature(root, flags[0].compat_flags,
>> + flags[1].compat_flags, COMPAT);
>> + if (ret)
>> + return ret;
>> +
>> + ret = check_feature(root, flags[0].compat_ro_flags,
>> + flags[1].compat_ro_flags, COMPAT_RO);
>> + if (ret)
>> + return ret;
>> +
>> + ret = check_feature(root, flags[0].incompat_flags,
>> + flags[1].incompat_flags, INCOMPAT);
>> + if (ret)
>> + return ret;
>> +
>> + trans = btrfs_start_transaction(root, 1);
>
> It's ok to use 0 here, it's a superblock change and not related the the
> metadata (similar to changing the label).
>
>> + if (IS_ERR(trans))
>> + return PTR_ERR(trans);
>> +
>> + spin_lock(&root->fs_info->super_lock);
>> + newflags = btrfs_super_compat_flags(super_block);
>> + newflags |= flags[0].compat_flags & flags[1].compat_flags;
>> + newflags &= ~(flags[0].compat_flags & ~flags[1].compat_flags);
>> + btrfs_set_super_compat_flags(super_block, newflags);
>> +
>> + newflags = btrfs_super_compat_ro_flags(super_block);
>> + newflags |= flags[0].compat_ro_flags & flags[1].compat_ro_flags;
>> + newflags &= ~(flags[0].compat_ro_flags & ~flags[1].compat_ro_flags);
>> + btrfs_set_super_compat_ro_flags(super_block, newflags);
>> +
>> + newflags = btrfs_super_incompat_flags(super_block);
>> + newflags |= flags[0].incompat_flags & flags[1].incompat_flags;
>> + newflags &= ~(flags[0].incompat_flags & ~flags[1].incompat_flags);
>> + btrfs_set_super_incompat_flags(super_block, newflags);
>> + spin_unlock(&root->fs_info->super_lock);
>> +
>> + return btrfs_end_transaction(trans, root);
>
> I think it's better to use btrfs_commit_transaction. The ioctl is about
> to do a permanent change, any crash between ioctl and full commit will
> revert to previous state of the features. This is not IMO desirable from
> administrators POV.
>
> (Sidenote, IOC_SET_FSLABEL needs the same update.)
Done, and I have a patch to fix the setlabel case as well.
>> +}
>> +
>> --- a/include/uapi/linux/btrfs.h 2013-09-09 17:49:10.808003254 -0400
>> +++ b/include/uapi/linux/btrfs.h 2013-09-09 17:49:12.483979430 -0400
>> @@ -184,6 +184,12 @@ struct btrfs_ioctl_fs_info_args {
>> __u64 reserved[124]; /* pad to 1k */
>> };
>>
>> +struct btrfs_ioctl_feature_flags {
>> + __u64 compat_flags;
>> + __u64 compat_ro_flags;
>> + __u64 incompat_flags;
>
> I wonder if it makes sense to add spare bytes here, but does not seem
> necessary.
We could double the size to allow for expansion, but I think it'd
probably make more sense to add another ioctl later if we end up getting
up to 64 features in a field.
>> +};
>> @@ -579,4 +585,10 @@ static inline char *btrfs_err_str(enum b
>> +#define BTRFS_IOC_GET_FEATURES _IOR(BTRFS_IOCTL_MAGIC, 54, \
>> + struct btrfs_ioctl_feature_flags)
>> +#define BTRFS_IOC_SET_FEATURES _IOW(BTRFS_IOCTL_MAGIC, 54, \
>> + struct btrfs_ioctl_feature_flags[2])
>> +#define BTRFS_IOC_GET_SUPPORTED_FEATURES _IOR(BTRFS_IOCTL_MAGIC, 54, \
>> + struct btrfs_ioctl_feature_flags[3])
>
> The ioctl number 54 clashes with the OOB dedup merged into 3.12, 55 is
> for the in-bound dedup and Anand has claimed 56. I've allocated 57 for
> you and updated th wiki page:
>
> https://btrfs.wiki.kernel.org/index.php/Project_ideas#Development_notes.2C_please_read
>
> Stefan's trick to reuse the same number is really neat.
Thanks, changed.
-Jeff
--
Jeff Mahoney
SUSE Labs
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 841 bytes --]
next prev parent reply other threads:[~2013-09-16 18:13 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-10 4:24 [patch 0/7] btrfs: Add ability to query/modify feature bits while mounted Jeff Mahoney
2013-09-10 4:24 ` [patch 1/7] [PATCH] btrfs: add ability to query/change feature bits online Jeff Mahoney
2013-09-16 17:26 ` David Sterba
2013-09-16 18:13 ` Jeff Mahoney [this message]
2013-09-10 4:24 ` [patch 2/7] btrfs: export supported featured to sysfs Jeff Mahoney
2013-09-10 4:24 ` [patch 3/7] btrfs: Add per-super attributes " Jeff Mahoney
2013-10-26 19:00 ` Alex Lyakas
2013-10-26 19:24 ` Jeff Mahoney
2013-09-10 4:24 ` [patch 4/7] btrfs: publish per-super features " Jeff Mahoney
2013-09-10 4:24 ` [patch 5/7] btrfs: Add publishing of unknown features in sysfs Jeff Mahoney
2013-09-10 4:24 ` [patch 6/7] btrfs: Add ability to change features via sysfs Jeff Mahoney
2013-09-10 4:24 ` [patch 7/7] btrfs: use feature attribute names to print better error messages Jeff Mahoney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52374A37.60402@suse.com \
--to=jeffm@suse.com \
--cc=clmason@fusionio.com \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.