On 2011-06-22, at 12:04 PM, Amir Goldstein wrote:

On Wed, Jun 22, 2011 at 8:47 PM, Andreas Dilger [off-list ref] wrote:

quoted

On 2011-06-22, at 6:04 AM, Amir Goldstein wrote:

quoted

On Wed, Jun 22, 2011 at 2:17 PM, Yongqiang Yang [off-list ref] wrote:

quoted

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?

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
- 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.

quoted

quoted

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.

quoted

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Cheers, Andreas