From: Jan Schmidt <list.btrfs@jan-o-sch.net>
To: dsterba@suse.cz, chris.mason@fusionio.com, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 1/2] Btrfs: rescan for qgroups
Date: Mon, 15 Apr 2013 07:44:35 +0200 [thread overview]
Message-ID: <516B93C3.4080306@jan-o-sch.net> (raw)
In-Reply-To: <20130410164741.GS18193@twin.jikos.cz>
On Wed, April 10, 2013 at 18:47 (+0200), David Sterba wrote:
> On Fri, Apr 05, 2013 at 01:38:16PM +0200, Jan Schmidt wrote:
>> + if (root->fs_info->qgroup_flags & BTRFS_QGROUP_STATUS_FLAG_RESCAN) {
>
> I was wondering if merging qgroup_flags with fs_state would make sense
> to you. There are currently 3 bits for qgroups, and it's a whole
> filesystem state anyway.
Well, yes, it can be done. I don't think it saves enough to justify the effort,
but feel free if you like. It's definitely not the purpose of this patch set :-)
>
>> + pr_debug("current progress key (%llu %u %llu), search_slot ret %d\n",
>> + fs_info->qgroup_rescan_progress.objectid,
>> + fs_info->qgroup_rescan_progress.type,
>> + fs_info->qgroup_rescan_progress.offset, ret);
>
> Please use (unsigned long long) for u64 types (objectid, offset).
>
>> --- a/include/uapi/linux/btrfs.h
>> +++ b/include/uapi/linux/btrfs.h
>> @@ -376,12 +376,17 @@ struct btrfs_ioctl_get_dev_stats {
>>
>> #define BTRFS_QUOTA_CTL_ENABLE 1
>> #define BTRFS_QUOTA_CTL_DISABLE 2
>> -#define BTRFS_QUOTA_CTL_RESCAN 3
>> +/* 3 has formerly been reserved for BTRFS_QUOTA_CTL_RESCAN */
>
> It's not clear if 3 can be reused or not. If yes, there's no need for
> the comment, if not, a #define should be left in place to capture the
> value.
It shouldn't. I just wanted to
1) make sure there are no users left and
2) point out to the next rescan code editor that this is not the flag he should
be looking for.
My new approach to satisfy both goals now is to leave the #define in there and
add __UNUSED to the end of the name.
>> struct btrfs_ioctl_quota_ctl_args {
>> __u64 cmd;
>> __u64 status;
>> };
>>
>> +struct btrfs_ioctl_quota_rescan_args {
>> + __u64 flags;
>> + __u64 progress;
>
> Like I'm always worried about future etensions, adding a few reserved[]
> does not hurt.
Thanks, v2 to come.
-Jan
next prev parent reply other threads:[~2013-04-15 5:44 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-05 11:38 [PATCH 0/2] Btrfs: quota rescan for 3.10 Jan Schmidt
2013-04-05 11:38 ` [PATCH 1/2] Btrfs: rescan for qgroups Jan Schmidt
2013-04-05 13:05 ` Josef Bacik
2013-04-10 16:14 ` David Sterba
2013-04-10 16:47 ` David Sterba
2013-04-15 5:44 ` Jan Schmidt [this message]
2013-04-15 5:58 ` Jan Schmidt
2013-04-15 6:08 ` Wang Shilong
2013-04-15 6:56 ` Jan Schmidt
2013-04-15 7:19 ` Wang Shilong
2013-04-15 10:53 ` Arne Jansen
2013-04-05 11:38 ` [PATCH 2/2] Btrfs: automatic rescan after "quota enable" command Jan Schmidt
2013-04-05 12:30 ` Wang Shilong
2013-04-06 6:20 ` [PATCH 0/2] Btrfs: quota rescan for 3.10 Wang Shilong
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=516B93C3.4080306@jan-o-sch.net \
--to=list.btrfs@jan-o-sch.net \
--cc=chris.mason@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