xfs
[Top] [All Lists]

Re: [PATCH v2] xfstests: add a new test case for ext4 indirect-based fil

To: xfs@xxxxxxxxxxx, linux-ext4@xxxxxxxxxxxxxxx, Zheng Liu <wenqing.lz@xxxxxxxxxx>
Subject: Re: [PATCH v2] xfstests: add a new test case for ext4 indirect-based file
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Wed, 20 Mar 2013 00:37:42 -0500
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20130320054555.GB4017@xxxxxxxxx>
References: <1363683183-7392-1-git-send-email-wenqing.lz@xxxxxxxxxx> <51489267.7080202@xxxxxxxxxxx> <20130320054555.GB4017@xxxxxxxxx>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
On 3/20/13 12:45 AM, Zheng Liu wrote:
>>> +f6aeca13ec49e5b266cd1c913cd726e3
>>> > > +       12. unwritten -> data -> unwritten
>> > 
>> > It's a little odd that the output contains "unwritten" when this test
>> > is explicitly for testing *without* unwritten extents.  Should this be
>> > cleaned up a little in common.punch, maybe?
> I will try to define a new function called _test_indirect_punch() to
> test punching hole without unwritten extent.

It's just the helper which prints "unwritten" regardless of what
is passed as "$alloc_cmd" to _test_generic_punch, right... so there's
nothing wrong with the test, really - it's just odd output.

I'm not sure it's worth a big copy & paste just to change
the output text, but if you can think of something simple to clean
it up, it might be worth it.

-Eric

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