From: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
To: Omar Sandoval <osandov@osandov.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs-progs: utils: negative numbers are more plausible than sizes over 8 EiB
Date: Sat, 3 Dec 2016 15:30:03 -0500 [thread overview]
Message-ID: <20161203203003.GU8685@hungrycats.org> (raw)
In-Reply-To: <20161203182517.GA18526@mew>
[-- Attachment #1: Type: text/plain, Size: 3091 bytes --]
On Sat, Dec 03, 2016 at 10:25:17AM -0800, Omar Sandoval wrote:
> On Sat, Dec 03, 2016 at 01:19:38AM -0500, Zygo Blaxell wrote:
> > I got tired of seeing "16.00EiB" whenever btrfs-progs encounters a
> > negative size value.
> >
> > e.g. during filesystem shrink we see:
> >
> > Unallocated:
> > /dev/mapper/testvol0 16.00EiB
> >
> > Interpreting this as a signed quantity is much more useful:
> >
> > Unallocated:
> > /dev/mapper/testvol0 -26.29GiB
> >
> > Signed-off-by: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
> > ---
> > utils.c | 13 ++++++++-----
> > 1 file changed, 8 insertions(+), 5 deletions(-)
> >
> > diff --git a/utils.c b/utils.c
> > index 69b580a..bd2b66e 100644
> > --- a/utils.c
> > +++ b/utils.c
> > @@ -2594,20 +2594,23 @@ static const char* unit_suffix_binary[] =
> > static const char* unit_suffix_decimal[] =
> > { "B", "kB", "MB", "GB", "TB", "PB", "EB"};
> >
> > -int pretty_size_snprintf(u64 size, char *str, size_t str_size, unsigned unit_mode)
> > +int pretty_size_snprintf(u64 usize, char *str, size_t str_size, unsigned unit_mode)
> > {
> > int num_divs;
> > float fraction;
> > - u64 base = 0;
> > + s64 base = 0;
> > int mult = 0;
> > const char** suffix = NULL;
> > - u64 last_size;
> > + s64 last_size;
> >
> > if (str_size == 0)
> > return 0;
> >
> > + /* Negative numbers are more plausible than sizes over 8 EiB. */
> > + s64 size = (s64)usize;
>
> Just make pretty_size_snprintf() take an s64 size so it's clear from the
> function signature that it's signed instead of hidden in the definition.
I intentionally buried the unsigned -> signed conversion in the lowest
level function so I wouldn't trigger signed/unsigned conversion warnings
at all 46 call sites for pretty_size_mode. The btrfs code uses u64
endemically for all size data, and I wasn't about to try to change that.
The word "pretty" in the function name should imply that what comes out
is a possibly lossy transformation of what goes in. Since "16.00EiB"
is much more lossy than "-29.96GiB", I believe I am merely reducing the
lossiness quantitatively rather than qualitatively.
On the other hand, the signed/unsigned warning isn't enabled by default
in this project. I can certainly do it that way if you prefer.
> > +
> > if ((unit_mode & ~UNITS_MODE_MASK) == UNITS_RAW) {
> > - snprintf(str, str_size, "%llu", size);
> > + snprintf(str, str_size, "%lld", size);
> > return 0;
> > }
> >
> > @@ -2642,7 +2645,7 @@ int pretty_size_snprintf(u64 size, char *str, size_t str_size, unsigned unit_mod
> > num_divs = 0;
> > break;
> > default:
> > - while (size >= mult) {
> > + while ((size < 0 ? -size : size) >= mult) {
> > last_size = size;
> > size /= mult;
> > num_divs++;
> > --
> > 2.1.4
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
prev parent reply other threads:[~2016-12-03 20:30 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-03 6:19 [PATCH] btrfs-progs: utils: negative numbers are more plausible than sizes over 8 EiB Zygo Blaxell
2016-12-03 18:25 ` Omar Sandoval
2016-12-03 20:30 ` Zygo Blaxell [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=20161203203003.GU8685@hungrycats.org \
--to=ce3g8jdj@umail.furryterror.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=osandov@osandov.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.