On Thu, Jun 23, 2011 at 2:24 AM, Andreas Dilger <adilger@xxxxxxxxx> wrote:
> On 2011-06-22, at 12:04 PM, Amir Goldstein wrote:
>> On Wed, Jun 22, 2011 at 8:47 PM, Andreas Dilger <adilger@xxxxxxxxx> wrote:
>>> On 2011-06-22, at 6:04 AM, Amir Goldstein wrote:
>>>
>>>> On Wed, Jun 22, 2011 at 2:17 PM, Yongqiang Yang <xiaoqiangnk@xxxxxxxxx> 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?
>
> What is the benefit of having this, compared to just calling the ioctl and
> getting -ENOTSUPP or -ENOTTY as the return code back?
>
I really don't know.
If anyone objects to the old way of -ENOTSUPP being the official way
to advertise
capabilities, speak now.
> Two issues with "online_resize", I guess:
> - firstly that this name is very generic, and "online resize" has been
> supported for a long time already
Yeah, I know, but it seems goofy to call it new_online_resize,
or 64bit_online_resize, given the the latter is not yet supported.
> - creating a /sys/fs/ext4/features entry for just this feature is
> inconsistent with whether the kernel supports any other features.
>
> In this case of "online_resize" it is OK if the _current_ kernel only
> supports this feature, since the resize will be completed and shouldn't
> impact the long-term usability of the filesystem. In some sense, even
> using "lazy_itable_init" is broken in this regard, since there is no
> guarantee that a new filesystem formatted on that kernel will actually
> be run on the same kernel, and it may leave the inode table uninitialized
> on disk while it runs on some older kernel. Not a big danger, since the
> zeroing should happen fairly quickly, but it will probably happen to
> someone.
>
> I just want to make sure that we don't get into a bad habit of just
> checking what features the current kernel provides and assume that it
> is safe to do something to the filesystem that isn't usable on another
> kernel.
>
>
>>>> 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@xxxxxxxxxxxxxxx
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>
>
> Cheers, Andreas
>
>
>
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
