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 for Android: free password hash cracker in your pocket

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

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

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.

> 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