linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 --]

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).