XFS Test Case:252 - Shows Wrong Output

[Amit Sahrawat]

This has to be an issue with everyone who is using XFS version which is not
supporting "fpunch" but still none has raised this. As per my view, the
support checking function *_require_xfs_io_falloc_punch() *is not working
correctly otherwise it should return from that point.

*Instead of:*
echo $testio | grep -q "not found"
If we are sure of a *"hole"* from that command, then we can grep for "hole"
in $testio.

Please correct me if I am wrong.

Thanks & Regards,
Amit Sahrawat




On Thu, Jun 23, 2011 at 5:00 PM, Amit Sahrawat <amit.sahrawat83 at gmail.com>wrote:

> What if we modify this *_require_xfs_io_falloc_punch()? T*o check whether
> "Hole" is created or not? This seems valid point for checking punch Support.
>
> Thanks & Regards,
> Amit Sahrawat
>
>
>
> On Thu, Jun 23, 2011 at 4:27 PM, Amit Sahrawat <amit.sahrawat83 at gmail.com>wrote:
>
>> This is linked with new feature.. Add punch support, although the code
>> existed before also, but the 'punch' has been specifically handled through
>> cmd = XFS_IOC_UNRESVP.
>>
>> Also, *fallocate* is moved out from  *'xfs_iops.c'* to 'file operations'
>> in *xfs_file.c*, which handles the case for
>>
>> if (mode & ~(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE))
>>                return -EOPNOTSUPP;
>> ...
>> if(mode & FALLOC_FL_PUNCH_HOLE)
>>                 cmd = XFS_IOC_UNRESVSP;
>> ...
>> Now, for old kernels, how to make sure that this test case does not
>> execute or return meaningful error? without changing the kernel code it will
>> not return error;
>> Since, *FALLOC_FL_KEEP_SIZE *this is true and the command work with
>> XFS_IOC_RESVP.
>>
>> Please suggest.
>>
>>
>> Thanks & Regards,
>> Amit Sahrawat
>>
>>
>>
>> On Thu, Jun 23, 2011 at 12:06 PM, Amit Sahrawat <
>> amit.sahrawat83 at gmail.com> wrote:
>>
>>> Fortunately or Unfortunately I have 2.6.31(x86) and 2.6.35.13(ARM) and
>>> both do not support "fpunch". As per your earlier mail - 2.6.35.y does not
>>> support "fpunch" so I though of trying on 2.6.31.y.
>>>
>>> I will check out for the return errors in this condition and will update
>>> more on this.
>>>
>>> Thanks & Regards,
>>> Amit Sahrawat
>>>
>>>
>>>
>>> On Thu, Jun 23, 2011 at 11:50 AM, Dave Chinner <david at fromorbit.com>wrote:
>>>
>>>> On Thu, Jun 23, 2011 at 11:21:26AM +0530, Amit Sahrawat wrote:
>>>> > Hi,
>>>> >
>>>> > *PLATFORM      -- Linux/i686 localhost 2.6.31.5-127.fc12.i686.PAE*
>>>>                                         ^^^^^^^^^^^
>>>> >
>>>> > The output as per the command mentioned by you:
>>>> > [root at localhost xfstests-2011-05-11]# xfs_io -f -c "truncate 20k" -c
>>>> "falloc
>>>> > 0 20k" -c "pwrite 0k 8k" -c "fs
>>>> > ync" -c "pwrite 12k 8k" -c "fsync" -c "fpunch 4k 12k" -c "fiemap -v"
>>>> > /media/c/newfile
>>>> > wrote 8192/8192 bytes at offset 0
>>>> > 8 KiB, 2 ops; 0.0000 sec (434.028 MiB/sec and 111111.1111 ops/sec)
>>>> > command "fs
>>>> > ync" not found
>>>> > wrote 8192/8192 bytes at offset 12288
>>>> > 8 KiB, 2 ops; 0.0000 sec (977 MiB/sec and 250000.0000 ops/sec)
>>>> > /media/c/newfile:
>>>> > * EXT: FILE-OFFSET      BLOCK-RANGE      TOTAL FLAGS
>>>> >    0: [0..15]:         176..191            16   0x0
>>>> >    1: [16..23]:        192..199             8 0x800
>>>> >    2: [24..39]:        200..215            16   0x1
>>>> > *
>>>>
>>>> The fpunch command did not punch the range out.
>>>>
>>>> Amit, once again you're testing on a kernel (2.6.31) that does not
>>>> support the punch operation. As I suggested previously, you need to
>>>> find out why the fpunch command is not returning an error as that is
>>>> root cause of your failures.
>>>>
>>>> Cheers,
>>>>
>>>> Dave.
>>>> --
>>>> Dave Chinner
>>>> david at fromorbit.com
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20110624/70206c6b/attachment.htm>