[Top] [All Lists]

Re: XFS Test Case:252 - Shows Wrong Output

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: XFS Test Case:252 - Shows Wrong Output
From: Amit Sahrawat <amit.sahrawat83@xxxxxxxxx>
Date: Fri, 24 Jun 2011 12:45:56 +0530
Cc: Allison Henderson <achender@xxxxxxxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dsH1cFg2Cnjw6cKs0AkEBGONV/bei6tKq4g6m22gSaM=; b=Kf/6or5AqnMI25C0u/e4eycy5IB6bgRs/HRCRkUy3s843bgV5aZiWKNFOo/iHfw8ru 4cW796/FU3Qlr4rXHKN5IgnAhbzyyyygECAskVGf/5TTsv5eAxA9Bn0ZiRvsfv7JdLPa SKFy5f94VYSKFUxmQjQSRZ8O2x7eWqXAgrdXY=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=WrgTlqHl1tC/ndQ7RYYd+WhcJthhQakquApVYvAlFRgQmsWDq1L1jw4LwN93/Bu1vN /+BF2NRAWxnM1fbnwzSXa6XL41I0OAD+fhBbdLRycCqcyVe/cxGHUVlQPsaW5N7Ro/ZW MdL3rPhz0jfyP7wUwcJXOlhKGPDmlNawdExp0=
In-reply-to: <BANLkTin8oJi04CCrtGVsxFGiA9PLQEEtpA@xxxxxxxxxxxxxx>
References: <BANLkTinBNa9ox+jDaorBoKdhoQQzTUA58A@xxxxxxxxxxxxxx> <BANLkTi=wHAxYuLE33AVsc2rp0eEm5GB40w@xxxxxxxxxxxxxx> <4E022818.7030406@xxxxxxxxxxxxxxxxxx> <BANLkTimuv183W0ef0aYCySWPnv9rLqNuww@xxxxxxxxxxxxxx> <20110623062030.GY32466@dastard> <BANLkTi=2rTU2R_hGGeMhLYzM6FKPOW0L8w@xxxxxxxxxxxxxx> <BANLkTinQig04y6Rc9MHGSfpbTSKZpmtHpQ@xxxxxxxxxxxxxx> <BANLkTin8oJi04CCrtGVsxFGiA9PLQEEtpA@xxxxxxxxxxxxxx>
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@xxxxxxxxx> wrote:
What if we modify this _require_xfs_io_falloc_punch()? To 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@xxxxxxxxx> wrote:
This is linked with new feature.. Add punch support, although the code existed before also, but the 'punch' has been specifically handled through
Also, fallocate is moved out from  'xfs_iops.c' to 'file operations' in xfs_file.c, which handles the case for   
               return -EOPNOTSUPP;
                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@xxxxxxxxx> wrote:
Fortunately or Unfortunately I have 2.6.31(x86) and 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@xxxxxxxxxxxxx> wrote:
On Thu, Jun 23, 2011 at 11:21:26AM +0530, Amit Sahrawat wrote:
> Hi,
> *PLATFORM      -- Linux/i686 localhost*
> 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:
>    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.


Dave Chinner

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