From: "Theodore Ts'o" <tytso@mit.edu>
To: Jan Kara <jack@suse.cz>
Cc: "Kiselev, Oleg" <okiselev@amazon.com>,
"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH 2/2] ext4: avoid resizing to a partial cluster size
Date: Fri, 15 Jul 2022 07:48:28 -0400 [thread overview]
Message-ID: <YtFUDIk589glIHSf@mit.edu> (raw)
In-Reply-To: <20220715093518.tzl2upullc5pymo2@quack3>
On Fri, Jul 15, 2022 at 11:35:18AM +0200, Jan Kara wrote:
> > available for the filesystem having an “odd” size. Our preference is for
> > the utilities to silently fix the fs size down to the nearest “safe” size
> > rather than get sporadic errors. I had submitted a patch for resize2fs
> > that rounds the fs target size down to the nearest cluster boundary. In
> > principle it’s similar to the size-rounding that is done now for 4K
> > blocks. Using updated e2fsprogs isn’t mandatory for using ext4 in the
> > newer kernels, so making the kernel safe(r) for bigalloc resizes seems
> > like a good idea.
>
> I see. Honestly, doing automatic "fixups" of passed arguments to syscalls /
> ioctls has bitten us more than once in the past. That's why I'm cautious
> about that. It seems convenient initially but then when contraints change
> (e.g. you'd want to be rounding to a different number) you suddently find
> you have no way to extend the API without breaking some userspace. That's
> why I prefer to put these "rounding convenience" functions into userspace.
>
> That being said I don't feel too strongly about this particular case so I
> guess I'll defer the final decision about the policy to Ted.
In this particular case, a file system whose size is not a multiple of
cluster size is never going to be valid, so having the resize ioctl
round down the requested size to largest valid size seems to be a safe
(and useful) thing to do.
- Ted
prev parent reply other threads:[~2022-07-15 11:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-30 2:17 [PATCH 2/2] ext4: avoid resizing to a partial cluster size Kiselev, Oleg
2022-07-14 13:52 ` Jan Kara
2022-07-15 1:00 ` Kiselev, Oleg
2022-07-15 9:35 ` Jan Kara
2022-07-15 11:48 ` Theodore Ts'o [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YtFUDIk589glIHSf@mit.edu \
--to=tytso@mit.edu \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=okiselev@amazon.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.