From: Alex Elder <aelder@sgi.com>
To: Boris Ranto <branto@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>,
Sandeen <sandeen@redhat.com>, xfs-oss <xfs@oss.sgi.com>
Subject: Re: xfstests 258: Test xfs fs creation with fs size close to 4 TB
Date: Thu, 22 Sep 2011 11:30:20 -0500 [thread overview]
Message-ID: <1316709020.2009.20.camel@doink> (raw)
In-Reply-To: <1316680229.6246.21.camel@dhcp-26-208.brq.redhat.com>
On Thu, 2011-09-22 at 10:30 +0200, Boris Ranto wrote:
> On Wed, 2011-09-21 at 11:54 -0500, Alex Elder wrote:
> > On Wed, 2011-09-21 at 15:52 +0200, Boris Ranto wrote:
> > > mkfs.xfs failed to create xfs filesystems with 4 TB minus few bytes due
> > > to round up error in mkfs.xfs code.
> > >
> > > This test case is a regression test for the fs creation problem.
> > >
> > > I've tested the test case with mkfs.xfs patch (in the form posted by
> > > Eric Sandeen) and the test passed (and therefore the patch fixed the
> > > issue for me).
> > >
> > > Signed-off-by: Boris Ranto <branto@redhat.com>
> >
> > This looks OK, but I'm a little concerned about the
> > shell's ability to handle > 32-bit values in its
> > arithmetic expressions (within $((...))).
> >
> > Using ${fourtb} works for me, but I just don't know
> > whether it is written somewhere that bash always
> > supports 64-bit (or even arbitrary) precision values.
> >
> > Do you know?
> >
> > Same general concern goes for dd, but I am more inclined
> > to think it can handle large numbers.
> >
> > Otherwise this looks good to me (though I haven't yet
> > tried it out).
> >
> > Reviewed-by: Alex Elder <aelder@sgi.com>
> >
> > . . .
> >
> > _______________________________________________
> > xfs mailing list
> > xfs@oss.sgi.com
> > http://oss.sgi.com/mailman/listinfo/xfs
>
> I'm not sure whether bash guarantees at least 64-bit precision values in
> its arithmetic operations.
> Therefore I suppose the values can be computed in advance in this case
> and the arithmetic operation can be simply left out:
This at least makes it so we only have to worry about
one program (dd) handling >32-bit values correctly.
Based on that alone I guess I prefer it. However
there should be a comment that explains where the
numbers come from, i.e.:
# 4398046511103 = 2^42 - 1
# 4398046510592 = 2^42 - 512
# 4398046510080 = 2^42 - 1024
# 4398046510079 = 2^42 - 1025
# 4398046509056 = 2^42 - 2048
# 4398046507008 = 2^42 - 4096
If dd doesn't support numbers that big we aren't working
in an environment suitable for running xfstests. So
at least from my perspective, this is good enough.
Reviewed-by: Alex Elder <aelder@sgi.com>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2011-09-22 16:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-21 13:52 xfstests 258: Test xfs fs creation with fs size close to 4 TB Boris Ranto
2011-09-21 16:54 ` Alex Elder
2011-09-21 19:06 ` Arkadiusz Miśkiewicz
2011-09-22 8:30 ` Boris Ranto
2011-09-22 16:30 ` Alex Elder [this message]
2011-09-26 11:44 ` Christoph Hellwig
2011-09-26 12:18 ` Alex Elder
2011-09-26 15:59 ` Eric Sandeen
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=1316709020.2009.20.camel@doink \
--to=aelder@sgi.com \
--cc=branto@redhat.com \
--cc=hch@infradead.org \
--cc=sandeen@redhat.com \
--cc=xfs@oss.sgi.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.