xfs
[Top] [All Lists]

Re: [PATCH V2] xfstests 206: test for overflow in growfs size calculatio

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH V2] xfstests 206: test for overflow in growfs size calculation
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Fri, 29 May 2009 09:56:12 -0500
Cc: xfs mailing list <xfs@xxxxxxxxxxx>
In-reply-to: <20090529145025.GA9205@xxxxxxxxxxxxx>
References: <4A1EF50D.8090900@xxxxxxxxxx> <4A1EFE55.4020505@xxxxxxxxxxx> <20090529145025.GA9205@xxxxxxxxxxxxx>
User-agent: Thunderbird 2.0.0.21 (X11/20090320)
Christoph Hellwig wrote:
> On Thu, May 28, 2009 at 04:12:53PM -0500, Eric Sandeen wrote:
>> Test trim of last small AG for large filesystem resizes
>>
>> As reported at
>> http://article.gmane.org/gmane.comp.file-systems.xfs.general/29187
>> this trimming may cause an overflow in the new size calculation.
>>
>> Patch to fix it, and testcase at
>> http://article.gmane.org/gmane.comp.file-systems.xfs.general/29193
>>
>> V2: now with proper expected (resized) output!
> 
> This fails for me in really weird ways (Debian -testing, i386):
> 
> 
> --- 206.out   2009-05-29 14:44:54.000000000 +0000
> +++ 206.out.bad       2009-05-29 14:46:01.000000000 +0000
> @@ -1,30 +1,18 @@
>  QA output created by 206
>  === xfs_io ===
> +ftruncate: File too large

hm, 32-bit.  crud.  Should probably just restrict the test to 64-bit
systems, since we need a file > 16T.

What's weirder is that xfs_io shoulda caused an error and caused the
test to bail, I think.

As for the rest of it, I need better error handling I guess :)

-Eric

<Prev in Thread] Current Thread [Next in Thread>