All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Mahoney <jeffm@suse.com>
To: Stefan Behrens <sbehrens@giantdisaster.de>
Cc: Chris Mason <clmason@fusionio.com>,
	linux-btrfs <linux-btrfs@vger.kernel.org>,
	David Sterba <dsterba@suse.cz>
Subject: Re: [PATCH] btrfs: add ability to query/change feature bits online
Date: Tue, 03 Sep 2013 20:32:21 -0400	[thread overview]
Message-ID: <52267F95.9030108@suse.com> (raw)
In-Reply-To: <5225AB12.9050102@giantdisaster.de>

[-- Attachment #1: Type: text/plain, Size: 3252 bytes --]

On 9/3/13 5:25 AM, Stefan Behrens wrote:
> On Tue, 27 Aug 2013 15:17:54 -0400, Jeff Mahoney wrote:
>> There are some feature bits that require no offline setup and can
>> be enabled online. I've only reviewed extended irefs, but there will
>> probably be more.
>>
>> We introduce three new ioctls:
>> - BTRFS_IOC_GET_SUPPORTED_FEATURES: query the kernel for supported features
>> - BTRFS_IOC_GET_FEATURES: query the kernel for enabled features on a per-fs
>>   basis.
>> - BTRFS_IOC_ADD_FEATURES: enable new features on a per-fs basis.
>>
>> We introduce a new mask _SAFE_ONLINE that allows us to define which
>> features are safe to enable at runtime.
>>
>> The failure modes for BTRFS_IOC_ADD_FEATURES are as follows:
>> - Enabling a completely unsupported feature: warns and returns -ENOTSUPP
>> - Enabling a feature that can only be done offline: warns and returns -EPERM
>>
>> The structure passed in is not modified on return since it is possible
>> to isolate which features would bounce a -EPERM by subtracting the features
>> provided by a GET_SUPPORTED_FEATURES call.
>>
>> Signed-off-by: Jeff Mahoney <jeffm@suse.com>
> [...]
>> --- a/include/uapi/linux/btrfs.h	2013-08-27 11:02:35.062626912 -0400
>> +++ b/include/uapi/linux/btrfs.h	2013-08-27 11:03:32.006352802 -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;
>> +};
>> +
>>  /* balance control ioctl modes */
>>  #define BTRFS_BALANCE_CTL_PAUSE		1
>>  #define BTRFS_BALANCE_CTL_CANCEL	2
>> @@ -579,4 +585,10 @@ static inline char *btrfs_err_str(enum b
>>  				      struct btrfs_ioctl_get_dev_stats)
>>  #define BTRFS_IOC_DEV_REPLACE _IOWR(BTRFS_IOCTL_MAGIC, 53, \
>>  				    struct btrfs_ioctl_dev_replace_args)
>> +#define BTRFS_IOC_GET_FEATURES _IOR(BTRFS_IOCTL_MAGIC, 54, \
>> +				   struct btrfs_ioctl_feature_flags)
>> +#define BTRFS_IOC_ADD_FEATURES _IOW(BTRFS_IOCTL_MAGIC, 55, \
>> +				   struct btrfs_ioctl_feature_flags)
> 
> #define BTRFS_IOC_ADD_FEATURES _IOW(BTRFS_IOCTL_MAGIC, 54, \
> 				   struct btrfs_ioctl_feature_flags)
> 
> Using 54 for both would also be possible since the directions are
> different. _IOR(54) for the get ioctl and _IOW(54) for the set/add ioctl.
> 
> 
>> +#define BTRFS_IOC_GET_SUPPORTED_FEATURES _IOR(BTRFS_IOCTL_MAGIC, 56, \
>> +				   struct btrfs_ioctl_feature_flags[2])
> 
> This could share the type value 54 too, since the parameter size is
> different. There are only 8 bits for the type field.

Ah, yep. You're right.

> And in order to support clearing feature bits you could replace the add
> ioctl with a set ioctl and use a mask + value scheme.
> #define BTRFS_IOC_SET_FEATURES _IOW(BTRFS_IOCTL_MAGIC, 54, \
> 				   struct btrfs_ioctl_feature_flags[2])
> btrfs_ioctl_feature_flags[0] is the mask and
> btrfs_ioctl_feature_flags[1] is the value. Only bits that are set to one
> in the mask are taken from the value and modified in the filesystem flags.

Yep. Though for now I think I'd implement the clear as an EOPNOTSUPP.

-Jeff

-- 
Jeff Mahoney
SUSE Labs


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 841 bytes --]

  reply	other threads:[~2013-09-04  0:32 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-27 19:17 [PATCH] btrfs: add ability to query/change feature bits online Jeff Mahoney
2013-09-03  9:25 ` Stefan Behrens
2013-09-04  0:32   ` Jeff Mahoney [this message]
2013-09-09 16:56 ` David Sterba

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=52267F95.9030108@suse.com \
    --to=jeffm@suse.com \
    --cc=clmason@fusionio.com \
    --cc=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=sbehrens@giantdisaster.de \
    /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.