From: Ted Ts'o <tytso@mit.edu>
To: Lukas Czerner <lczerner@redhat.com>
Cc: linux-ext4@vger.kernel.org, sandeen@redhat.com
Subject: Re: [PATCH 1/2 v3] e2fsprogs: Fix how we treat user-spcified filesystem size
Date: Tue, 31 May 2011 19:45:17 -0400 [thread overview]
Message-ID: <20110531234517.GA2629@thunk.org> (raw)
In-Reply-To: <1305905808-31093-1-git-send-email-lczerner@redhat.com>
On Fri, May 20, 2011 at 05:36:47PM +0200, Lukas Czerner wrote:
> mke2fs and resize2fs allows specifying filesystem size as a parameter,
> former called as blocks-count. However it has been a little bit messy so
> this commit fixes it mainly by updating man pages.
>
> We can not specify filesystem size in blocks count without specifying
> blocksize as well. It is because we need blocks count to determine
> filesystem type, and we need filesystem type to determine blocksize. So
> it should not be allowed, however due to compatibility reason it should
> be still possible, so at least print warning message for now, so we can
> easily restrict that later.
>
> Filesystem size can be specified using units as suffixes. This was not
> documented for mke2fs, so this commits adds proper documentation into
> mke2fs man page.
>
> For the sake of completeness add 'b' (filesystem blocks) unit.
I'd much rather fix this by documenting that without a suffix, it will
be interpreted as the number of blocks if -b is specified, and that if
-b is not specified, it will be interpreted as kilobytes (but that
this usage is deprecated).
> @@ -37,6 +38,14 @@ unsigned long long parse_num_blocks2(const char *arg, int log_block_size)
> num >>= (1+log_block_size);
> break;
> case '\0':
> + case 'b':
> + if (!log_block_size) {
> + fprintf(stderr,
> + _("Warning: You should not specify filesystem "
> + "size without specifying block size '-b'. "
> + "Will assume 1024 byte blocks!\n"
> + ));
> + }
> break;
> default:
> return 0;
I'd much rather not add this, since there may be other programs using
parse_num_blocks2() that aren't mke2fs or tune2fs, where -b doesn't
make sense.
- Ted
prev parent reply other threads:[~2011-06-01 2:22 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-20 15:36 [PATCH 1/2 v3] e2fsprogs: Fix how we treat user-spcified filesystem size Lukas Czerner
2011-05-20 15:36 ` [PATCH 2/2 v3] mke2fs: use binary units in the man page Lukas Czerner
2011-05-20 15:44 ` [PATCH 1/2 v3] e2fsprogs: Fix how we treat user-spcified filesystem size Eric Sandeen
2011-05-31 23:45 ` Ted 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=20110531234517.GA2629@thunk.org \
--to=tytso@mit.edu \
--cc=lczerner@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=sandeen@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).