XFS Test Case:252 - Shows Wrong Output

XFS Test Case:252 - Shows Wrong Output

[Amit Sahrawat]

[-- Attachment #1.1: Type: text/plain, Size: 1709 bytes --]

While executing Test case no: 252 from xfstestsuites - I got Output
mismatch.

*Environment tried:*
*X86 : Linux version 2.6.31.5-127.fc12.i686.PAE*
*ARM: Linux version2.6.35.13*

On looking at the test case and then dividing the total case into invidual
test's I could somehow correlate the results as per the commands issues.
Complete output for the '13' commands in this case is as given below:

[root@localhost PROGS]# sh cmd.sh
  1. into a hole
0: [0..7]: hole
1: [8..23]: unwritten
2: [24..39]: hole
  2. into allocated space
0: [0..39]: data
  3. into unwritten space
0: [0..39]: unwritten
  4. hole -> data
0: [0..7]: hole
1: [8..15]: unwritten
2: [16..31]: data
3: [32..39]: hole
  5. hole -> unwritten
0: [0..7]: hole
1: [8..15]: unwritten
2: [16..31]: unwritten
3: [32..39]: hole
  6. data -> hole
0: [0..15]: data
1: [16..23]: unwritten
2: [24..39]: hole
  7. data -> unwritten
0: [0..15]: data
1: [16..31]: unwritten
2: [32..39]: hole
  8. unwritten -> hole
0: [0..23]: unwritten
1: [24..39]: hole
  9. unwritten -> data
0: [0..15]: unwritten
1: [16..31]: data
2: [32..39]: hole
  10. hole -> data -> hole
0: [0..7]: hole
1: [8..15]: unwritten
2: [16..23]: data
3: [24..31]: unwritten
4: [32..39]: hole
  11. data -> hole -> data
0: [0..15]: data
1: [16..23]: unwritten
2: [24..39]: data
  12. unwritten -> data -> unwritten
0: [0..15]: unwritten
1: [16..23]: data
2: [24..39]: unwritten
  13. data -> unwritten -> data
0: [0..15]: data
1: [16..23]: unwritten
2: [24..39]: data
[root@localhost PROGS]#
The above output seems as per the tests commands issue. Please correct me if
i am wrong.
If this correct, then for the test case we need to change 252.out file.

Thanks & Regards,
Amit Sahrawat

[-- Attachment #1.2: Type: text/html, Size: 2202 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: XFS Test Case:252 - Shows Wrong Output

[Amit Sahrawat]

[-- Attachment #1.1: Type: text/plain, Size: 2991 bytes --]

Dear All,
**
*Test Case:13
*        echo "  13. data -> unwritten -> data"
        rm -f $testfile
        $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \
                -c "$alloc_cmd 0 20k" \
                -c "pwrite 0k 8k" -c "fsync" \
                -c "pwrite 12k 8k" -c "fsync" \
                -c "$zero_cmd 4k 12k" \
                -c "$map_cmd -v" $testfile | $filter_cmd
        [ $? -ne 0 ] && die_now

*After executing individual case like this:
*testfile=/data/usb/sda3/252.testfile

echo "13. data -> unwritten -> data"
rm -f $testfile
xfs_io -f -c "truncate 20k" -c \
"falloc 0 20k" -c "pwrite 0k 8k" -c "fsync" -c "pwrite 12k 8k" -c  \
"fsync" -c "fpunch 4k 12k" -c "fiemap -v" $testfile | $filter_cmd

*Original Output(Taken from 252.out):
*        13. data -> unwritten -> data
0: [0..7]: data
1: [8..31]: hole
2: [32..39]: data
*Output in my case*
  13. data -> unwritten -> data
0: [0..15]: data
1: [16..23]: unwritten
2: [24..39]: data

Please let me know about the vailidity of this result.

Thanks & Regards,
Amit Sahrawat
On Wed, Jun 22, 2011 at 3:54 PM, Amit Sahrawat <amit.sahrawat83@gmail.com>wrote:

> While executing Test case no: 252 from xfstestsuites - I got Output
> mismatch.
>
> *Environment tried:*
> *X86 : Linux version 2.6.31.5-127.fc12.i686.PAE*
> *ARM: Linux version2.6.35.13*
>
> On looking at the test case and then dividing the total case into invidual
> test's I could somehow correlate the results as per the commands issues.
> Complete output for the '13' commands in this case is as given below:
>
> [root@localhost PROGS]# sh cmd.sh
>   1. into a hole
> 0: [0..7]: hole
> 1: [8..23]: unwritten
> 2: [24..39]: hole
>   2. into allocated space
> 0: [0..39]: data
>   3. into unwritten space
> 0: [0..39]: unwritten
>   4. hole -> data
> 0: [0..7]: hole
> 1: [8..15]: unwritten
> 2: [16..31]: data
> 3: [32..39]: hole
>   5. hole -> unwritten
> 0: [0..7]: hole
> 1: [8..15]: unwritten
> 2: [16..31]: unwritten
> 3: [32..39]: hole
>   6. data -> hole
> 0: [0..15]: data
> 1: [16..23]: unwritten
> 2: [24..39]: hole
>   7. data -> unwritten
> 0: [0..15]: data
> 1: [16..31]: unwritten
> 2: [32..39]: hole
>   8. unwritten -> hole
> 0: [0..23]: unwritten
> 1: [24..39]: hole
>   9. unwritten -> data
> 0: [0..15]: unwritten
> 1: [16..31]: data
> 2: [32..39]: hole
>   10. hole -> data -> hole
> 0: [0..7]: hole
> 1: [8..15]: unwritten
> 2: [16..23]: data
> 3: [24..31]: unwritten
> 4: [32..39]: hole
>   11. data -> hole -> data
> 0: [0..15]: data
> 1: [16..23]: unwritten
> 2: [24..39]: data
>   12. unwritten -> data -> unwritten
> 0: [0..15]: unwritten
> 1: [16..23]: data
> 2: [24..39]: unwritten
>   13. data -> unwritten -> data
> 0: [0..15]: data
> 1: [16..23]: unwritten
> 2: [24..39]: data
> [root@localhost PROGS]#
> The above output seems as per the tests commands issue. Please correct me
> if i am wrong.
> If this correct, then for the test case we need to change 252.out file.
>
> Thanks & Regards,
> Amit Sahrawat
>
>
>
>
>
>

[-- Attachment #1.2: Type: text/html, Size: 4164 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: XFS Test Case:252 - Shows Wrong Output

[Allison Henderson]

On 06/22/2011 03:48 AM, Amit Sahrawat wrote:
> echo "13. data ->  unwritten ->  data"
> rm -f $testfile
> xfs_io -f -c "truncate 20k" -c \
> "falloc 0 20k" -c "pwrite 0k 8k" -c "fsync" -c "pwrite 12k 8k" -c  \
> "fsync" -c "fpunch 4k 12k" -c "fiemap -v" $testfile | $filter_cmd
>
> *Original Output(Taken from 252.out):
> *        13. data ->  unwritten ->  data
> 0: [0..7]: data
> 1: [8..31]: hole
> 2: [32..39]: data
> *Output in my case*
>    13. data ->  unwritten ->  data
> 0: [0..15]: data
> 1: [16..23]: unwritten
> 2: [24..39]: data

Hi there,

I believe the -c "fpunch 4k 12k" is supposed to be what puts the hole 
there.  If I run the command you have above, the fiemap should show you 
a hole.  Something like this:

xfs_io -f -c "truncate 20k" -c "falloc 0 20k" -c "pwrite 0k 8k" -c 
"fsync" -c "pwrite 12k 8k" -c  "fsync" -c "fpunch 4k 12k" -c "fiemap -v" 
somefile

wrote 8192/8192 bytes at offset 0
8 KiB, 2 ops; 0.0000 sec (217.014 MiB/sec and 55555.5556 ops/sec)
wrote 8192/8192 bytes at offset 12288
8 KiB, 2 ops; 0.0000 sec (269.397 MiB/sec and 68965.5172 ops/sec)
somefile:
  EXT: FILE-OFFSET      BLOCK-RANGE      TOTAL FLAGS
    0: [0..7]:          296..303             8   0x0
    1: [8..31]:         hole                24
    2: [32..39]:        328..335             8   0x1

If you do not see the hole there, it could be that your punch hole 
operation is failing for some reason.

Allison Henderson

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: XFS Test Case:252 - Shows Wrong Output

[Allison Henderson]

On 06/22/2011 03:48 AM, Amit Sahrawat wrote:
> xfs_io -f -c "truncate 20k" -c \
> "falloc 0 20k" -c "pwrite 0k 8k" -c "fsync" -c "pwrite 12k 8k" -c  \
> "fsync" -c "fpunch 4k 12k" -c "fiemap -v" $testfile | $filter_cmd
>
> *Original Output(Taken from 252.out):
> *        13. data ->  unwritten ->  data
> 0: [0..7]: data
> 1: [8..31]: hole
> 2: [32..39]: data
> *Output in my case*
>    13. data ->  unwritten ->  data
> 0: [0..15]: data
> 1: [16..23]: unwritten
> 2: [24..39]: data
>
> Please let me know about the vailidity of this result.

Hi there,

It looks like the "fpunch 4k 12k" is supposed to be what puts the hole 
there.  If I run the command you have above, the fiemap should show a 
hole like this:

xfs_io -f -c "truncate 20k" -c "falloc 0 20k" -c "pwrite 0k 8k" -c 
"fsync" -c "pwrite 12k 8k" -c  "fsync" -c "fpunch 4k 12k" -c "fiemap -v" 
somefile
wrote 8192/8192 bytes at offset 0
8 KiB, 2 ops; 0.0000 sec (217.014 MiB/sec and 55555.5556 ops/sec)
wrote 8192/8192 bytes at offset 12288
8 KiB, 2 ops; 0.0000 sec (339.674 MiB/sec and 86956.5217 ops/sec)
somefile:
  EXT: FILE-OFFSET      BLOCK-RANGE      TOTAL FLAGS
    0: [0..7]:          256..263             8   0x0
    1: [8..31]:         hole                24
    2: [32..39]:        288..295             8   0x1

If you do not see the hole, it could be your punch hole operation is 
failing for some reason.

Allison Henderson

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: XFS Test Case:252 - Shows Wrong Output

[Dave Chinner]

On Wed, Jun 22, 2011 at 04:18:52PM +0530, Amit Sahrawat wrote:
> Dear All,
> **
> *Test Case:13
> *        echo "  13. data -> unwritten -> data"
>         rm -f $testfile
>         $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \
>                 -c "$alloc_cmd 0 20k" \
>                 -c "pwrite 0k 8k" -c "fsync" \
>                 -c "pwrite 12k 8k" -c "fsync" \
>                 -c "$zero_cmd 4k 12k" \
>                 -c "$map_cmd -v" $testfile | $filter_cmd
>         [ $? -ne 0 ] && die_now
> 
> *After executing individual case like this:
> *testfile=/data/usb/sda3/252.testfile
> 
> echo "13. data -> unwritten -> data"
> rm -f $testfile
> xfs_io -f -c "truncate 20k" -c \
> "falloc 0 20k" -c "pwrite 0k 8k" -c "fsync" -c "pwrite 12k 8k" -c  \
> "fsync" -c "fpunch 4k 12k" -c "fiemap -v" $testfile | $filter_cmd
> 
> *Original Output(Taken from 252.out):
> *        13. data -> unwritten -> data
> 0: [0..7]: data
> 1: [8..31]: hole
> 2: [32..39]: data
> *Output in my case*
>   13. data -> unwritten -> data
> 0: [0..15]: data
> 1: [16..23]: unwritten
> 2: [24..39]: data

FWIW, it would be much easier for us to understand your problem if
you simply posted the output of a failing "check 252" (it's a diff
of the output vs the golden output!) rather than a bunch of strange
mangled script outputs from whatever wrapper you are using to run
xfstests that nobody but you understand.

Anyway, I'm pretty sure that 2.6.35.y doesn't support punching holes
via the fallocate operation and so this check in the test:

_require_xfs_io_falloc_punch

is probably not detecting that punch is not supported correctly.
Perhaps that is what you need to check first...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: XFS Test Case:252 - Shows Wrong Output

[Amit Sahrawat]

[-- Attachment #1.1: Type: text/plain, Size: 4284 bytes --]

This is the original result I got after running test case : 252
[root@localhost xfstests-2011-05-11]# ./check -xfs 252
*FSTYP         -- xfs (non-debug)
PLATFORM      -- Linux/i686 localhost 2.6.31.5-127.fc12.i686.PAE
MKFS_OPTIONS  -- -f -bsize=4096 /dev/sdb4
MOUNT_OPTIONS -- -o context=system_u:object_r:nfs_t:s0 /dev/sdb4 /media/d*
252  - output mismatch (see 252.out.bad)
--- 252.out 2011-06-21 12:47:23.000000000 +0530
+++ 252.out.bad 2011-06-23 11:10:33.000000000 +0530
@@ -1,47 +1,51 @@
 QA output created by 252
  1. into a hole
+0: [0..7]: hole
+1: [8..23]: unwritten
+2: [24..39]: hole
  2. into allocated space
-0: [0..7]: data
-1: [8..23]: hole
-2: [24..39]: data
+0: [0..39]: data
  3. into unwritten space
-0: [0..7]: unwritten
-1: [8..23]: hole
-2: [24..39]: unwritten
+0: [0..39]: unwritten
  4. hole -> data
-0: [0..23]: hole
-1: [24..31]: data
-2: [32..39]: hole
+0: [0..7]: hole
+1: [8..15]: unwritten
+2: [16..31]: data
+3: [32..39]: hole
  5. hole -> unwritten
-0: [0..23]: hole
-1: [24..31]: unwritten
+0: [0..7]: hole
+1: [8..31]: unwritten
 2: [32..39]: hole
  6. data -> hole
-0: [0..7]: data
-1: [8..39]: hole
+0: [0..15]: data
+1: [16..23]: unwritten
+2: [24..39]: hole
  7. data -> unwritten
-0: [0..7]: data
-1: [8..23]: hole
-2: [24..31]: unwritten
-3: [32..39]: hole
+0: [0..15]: data
+1: [16..31]: unwritten
+2: [32..39]: hole
  8. unwritten -> hole
-0: [0..7]: unwritten
-1: [8..39]: hole
+0: [0..23]: unwritten
+1: [24..39]: hole
  9. unwritten -> data
-0: [0..7]: unwritten
-1: [8..23]: hole
-2: [24..31]: data
-3: [32..39]: hole
+0: [0..15]: unwritten
+1: [16..31]: data
+2: [32..39]: hole
  10. hole -> data -> hole
+0: [0..7]: hole
+1: [8..15]: unwritten
+2: [16..23]: data
+3: [24..31]: unwritten
+4: [32..39]: hole
  11. data -> hole -> data
-0: [0..7]: data
-1: [8..31]: hole
-2: [32..39]: data
+0: [0..15]: data
+1: [16..23]: unwritten
+2: [24..39]: data
  *12. unwritten -> data -> unwritten
*-0: [0..7]: unwritten
-1: [8..31]: hole
-2: [32..39]: unwritten
*+0: [0..15]: unwritten
+1: [16..23]: data
+2: [24..39]: unwritten
* * 13. data -> unwritten -> data
*-0: [0..7]: data
-1: [8..31]: hole
-2: [32..39]: data
*+0: [0..15]: data
+1: [16..23]: unwritten
+2: [24..39]: data
*Ran: 252
Failures: 252
Failed 1 of 1 tests
[root@localhost xfstests-2011-05-11]#
The above output if for kernel version 2.6.31..

Thanks & Regards,
Amit Sahrawat

On Thu, Jun 23, 2011 at 4:27 AM, Dave Chinner <david@fromorbit.com> wrote:

> On Wed, Jun 22, 2011 at 04:18:52PM +0530, Amit Sahrawat wrote:
> > Dear All,
> > **
> > *Test Case:13
> > *        echo "  13. data -> unwritten -> data"
> >         rm -f $testfile
> >         $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \
> >                 -c "$alloc_cmd 0 20k" \
> >                 -c "pwrite 0k 8k" -c "fsync" \
> >                 -c "pwrite 12k 8k" -c "fsync" \
> >                 -c "$zero_cmd 4k 12k" \
> >                 -c "$map_cmd -v" $testfile | $filter_cmd
> >         [ $? -ne 0 ] && die_now
> >
> > *After executing individual case like this:
> > *testfile=/data/usb/sda3/252.testfile
> >
> > echo "13. data -> unwritten -> data"
> > rm -f $testfile
> > xfs_io -f -c "truncate 20k" -c \
> > "falloc 0 20k" -c "pwrite 0k 8k" -c "fsync" -c "pwrite 12k 8k" -c  \
> > "fsync" -c "fpunch 4k 12k" -c "fiemap -v" $testfile | $filter_cmd
> >
> > *Original Output(Taken from 252.out):
> > *        13. data -> unwritten -> data
> > 0: [0..7]: data
> > 1: [8..31]: hole
> > 2: [32..39]: data
> > *Output in my case*
> >   13. data -> unwritten -> data
> > 0: [0..15]: data
> > 1: [16..23]: unwritten
> > 2: [24..39]: data
>
> FWIW, it would be much easier for us to understand your problem if
> you simply posted the output of a failing "check 252" (it's a diff
> of the output vs the golden output!) rather than a bunch of strange
> mangled script outputs from whatever wrapper you are using to run
> xfstests that nobody but you understand.
>
> Anyway, I'm pretty sure that 2.6.35.y doesn't support punching holes
> via the fallocate operation and so this check in the test:
>
> _require_xfs_io_falloc_punch
>
> is probably not detecting that punch is not supported correctly.
> Perhaps that is what you need to check first...
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@fromorbit.com
>

[-- Attachment #1.2: Type: text/html, Size: 5702 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: XFS Test Case:252 - Shows Wrong Output

[Amit Sahrawat]

[-- Attachment #1.1: Type: text/plain, Size: 2362 bytes --]

Hi,

*PLATFORM      -- Linux/i686 localhost 2.6.31.5-127.fc12.i686.PAE*

The output as per the command mentioned by you:
[root@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
*
Thanks & Regards,
Amit Sahrawat



On Wed, Jun 22, 2011 at 11:06 PM, Allison Henderson <
achender@linux.vnet.ibm.com> wrote:

> On 06/22/2011 03:48 AM, Amit Sahrawat wrote:
>
>> xfs_io -f -c "truncate 20k" -c \
>> "falloc 0 20k" -c "pwrite 0k 8k" -c "fsync" -c "pwrite 12k 8k" -c  \
>> "fsync" -c "fpunch 4k 12k" -c "fiemap -v" $testfile | $filter_cmd
>>
>> *Original Output(Taken from 252.out):
>> *        13. data ->  unwritten ->  data
>> 0: [0..7]: data
>> 1: [8..31]: hole
>> 2: [32..39]: data
>> *Output in my case*
>>   13. data ->  unwritten ->  data
>> 0: [0..15]: data
>> 1: [16..23]: unwritten
>> 2: [24..39]: data
>>
>> Please let me know about the vailidity of this result.
>>
>
> Hi there,
>
> It looks like the "fpunch 4k 12k" is supposed to be what puts the hole
> there.  If I run the command you have above, the fiemap should show a hole
> like this:
>
>
> xfs_io -f -c "truncate 20k" -c "falloc 0 20k" -c "pwrite 0k 8k" -c "fsync"
> -c "pwrite 12k 8k" -c  "fsync" -c "fpunch 4k 12k" -c "fiemap -v" somefile
> wrote 8192/8192 bytes at offset 0
> 8 KiB, 2 ops; 0.0000 sec (217.014 MiB/sec and 55555.5556 ops/sec)
> wrote 8192/8192 bytes at offset 12288
> 8 KiB, 2 ops; 0.0000 sec (339.674 MiB/sec and 86956.5217 ops/sec)
>
> somefile:
>  EXT: FILE-OFFSET      BLOCK-RANGE      TOTAL FLAGS
>   0: [0..7]:          256..263             8   0x0
>
>   1: [8..31]:         hole                24
>   2: [32..39]:        288..295             8   0x1
>
> If you do not see the hole, it could be your punch hole operation is
> failing for some reason.
>
> Allison Henderson
>
>

[-- Attachment #1.2: Type: text/html, Size: 3539 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: XFS Test Case:252 - Shows Wrong Output

[Dave Chinner]

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@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@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: XFS Test Case:252 - Shows Wrong Output

[Amit Sahrawat]

[-- Attachment #1.1: Type: text/plain, Size: 1737 bytes --]

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@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@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@fromorbit.com
>

[-- Attachment #1.2: Type: text/html, Size: 2520 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: XFS Test Case:252 - Shows Wrong Output

[Amit Sahrawat]

[-- Attachment #1.1: Type: text/plain, Size: 2645 bytes --]

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@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@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@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@fromorbit.com
>>
>
>

[-- Attachment #1.2: Type: text/html, Size: 4018 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: XFS Test Case:252 - Shows Wrong Output

[Amit Sahrawat]

[-- Attachment #1.1: Type: text/plain, Size: 3024 bytes --]

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@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@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@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@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@fromorbit.com
>>>
>>
>>
>

[-- Attachment #1.2: Type: text/html, Size: 4745 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: XFS Test Case:252 - Shows Wrong Output

[Amit Sahrawat]

[-- Attachment #1.1: Type: text/plain, Size: 3694 bytes --]

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@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@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@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@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@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@fromorbit.com
>>>>
>>>
>>>
>>
>

[-- Attachment #1.2: Type: text/html, Size: 5902 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: XFS Test Case:252 - Shows Wrong Output

[Alex Elder]

On Fri, 2011-06-24 at 12:45 +0530, Amit Sahrawat wrote:
> 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

I think what you are saying is that in your environment,
_require_xfs_io_falloc_punch() is not properly deciding
whether the fpunch operation is supported.  And you are
suggesting a way to determine it properly, is that right?

Unfortunately it is difficult to know whether your
suggestion is a proper fix without knowing details of
your current system, as well as details about what
you are seeing that is incorrect.

We welcome suggested fixes from people.  Often that
takes the form of a patch that proposes a fix, but
if enough precise information is provided about the
problem we can sometimes develop a fix for you.

Can you supply either a patch with a proposed fix,
or else provide more information about exactly
what you are seeing?  Otherwise I don't think
we're going to be able to help.

Thanks.

					-Alex

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs