linux-ext4 - Re: exclude bitmap update

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 22 Jun 2011 21:04:29 +0300
From:	Amir Goldstein <amir73il@...il.com>
To:	Andreas Dilger <adilger@...ger.ca>
Cc:	Yongqiang Yang <xiaoqiangnk@...il.com>,
	Theodore Tso <tytso@....edu>,
	Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: exclude bitmap update

On Wed, Jun 22, 2011 at 8:47 PM, Andreas Dilger <adilger@...ger.ca> wrote:
> On 2011-06-22, at 6:04 AM, Amir Goldstein wrote:
>
>> On Wed, Jun 22, 2011 at 2:17 PM, Yongqiang Yang <xiaoqiangnk@...il.com> wrote:
>>> If I am right, resize in userspace will be simpler.
>>
>> Yes, it will. very simple.
>> The only thing you need to do in userspace is check for online resize
>> support in the kernel,
>> like mke2fs does for lazy_itable_init:
>>
>>       if (access("/sys/fs/ext4/features/lazy_itable_init", R_OK) == 0)
>>               lazy_itable_init = 1;
>>
>>
>> We can either just create the /sys/fs/ext4/features/online_resize entry in
>> ext4_feat_attrs array with: EXT4_INFO_ATTR(online_resize);
>> to indicate the new ioctl is implemented by the kernel.
>>
>> Or we can export the specific features which are supported by online
>> resize with:
>> EXT4_RO_ATTR(online_resize);
>> and an online_resize_show() function.
>
> No, this is all much too complex, and not needed.

I suppose you are referring to advertising the features supported by resize.
I did get a bit carried away there ;-)

I see no harm is advertising the new ioctl support via
/sys/fs/ext4/features/online_resize.
Do you have an objection to that?

>
>> Maybe somebody has a better suggestion or maybe we should just
>> let the ioctl return ENOTSUP, like today, with unsupported features for resize.
>
> Right.  This will fail for old kernels where the ioctl isn't supported, and
> succeed for new kernels where it is supported, and has no added complexity.
>
>> Then, for example, if Andreas's group will add support for online resize with
>> 64bit and meta_bg features, they could use this interface to advertise the
>> new resize capabilities to userspace.
>
> There is no need for this either.  If the kernel can do the resize (regardless
> of the features involved) it will succeed, and if it fails, it fails.  Passing
> the new filesystem size is all that is needed.  If the user wants to enable
> META_BG for resizing, this can be done via tune2fs/resize2fs from userspace
> with the "s_first_meta_bg" value set to be the group after the end of the
> filesystem, or possibly after the last group that would fit within the last
> regular group descriptor block.
>
> Cheers, Andreas
>
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html