(2012/09/18 21:10), David Sterba wrote:
> On Tue, Sep 18, 2012 at 10:28:48AM +0900, Hidetoshi Seto wrote:
>> diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
>> index fa5c45b..3eb0551 100644
>> --- a/fs/btrfs/ctree.h
>> +++ b/fs/btrfs/ctree.h
>> @@ -458,8 +458,11 @@ struct btrfs_super_block {
>>
>> __le64 cache_generation;
>>
>> + /* default mount options */
>> + unsigned long default_mount_opt;
>
> you need to use __le64 here, unsigned long has not fixed size
Indeed. I'll use __le64 next time.
>> diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
>> index e239915..7ef4a2e 100644
>> --- a/fs/btrfs/super.c
>> +++ b/fs/btrfs/super.c
>> @@ -340,6 +340,8 @@ int btrfs_parse_options(struct btrfs_root *root, char
>> *options)
>> char *compress_type;
>> bool compress_force = false;
>>
>> + info->mount_opt = info->super_copy->default_mount_opt;
>
> the options have to respect some priority, eg. when I set default
> options to a filesystem, but mount with a different set, I expect that
> the explicit flags apply and override the defaults.
>
> I don't remember if this was discussed in the mailinglist or on IRC
> only, should be easy to dig up if needed.
At least I don't know whether this was already disscussed or not.
Now my code gives priority to the default options, and it would not
be so difficult in case if we have opposing options like "ssd" vs
"nossd", and "space_cache" vs "no_space_cache"...
Or we could use the default options only if there is no options
specified when it is being mount, but it will make the default
options useless. Humm, I'll try to pull together my thoughts
prior to my next post.
Thanks,
H.Seto
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
