[LTP] Submitting patch

[LTP] Submitting patch

[jyotiv]

[-- Attachment #1: Type: text/plain, Size: 1283 bytes --]

PATCH IS CREATED FOR ltp-full-20090630.

I am submitting a patch to kernel/fs/fs_di

In this file data integity is performed by creating the file at
different directory depth and then by comparing with original file.

To this I have added one more approach to perform integrity test.
1. Creating two fragmented files each of size DiskSize/2.
2. Then comapring against the original file.
3. If not equal test case fails.

My ultimate goal in creating fragmented files is that,
1. It creates many extents (fragments for each file)
2. FS code may behave wrong at corner cases which may come into picture
   after many extents gets added to the file.
3. Data corruption chances are there 
     i. when file metadata updation is not proper (corner cases when fragments are more)
     ii.If write and read is not matching (write operation might have updated the block 
        number some where and read may skip that block in some corner cases)
4. In reality fragments can occur only after much usage of the disk(create/delete file)
5. This is good test case for bigger size disk.(it can create more extents)


To: ltp-list@lists.sourceforge.net
Cc: subrata@linux.vnet.ibm.com
Bcc: Jyoti <jyotiv@linux.vnet.ibm.com>
Subject: Submitting patch 
Reply-To: Jyoti <jyotiv@linux.vnet.ibm.com>


[-- Attachment #2: fs_di.patch --]
[-- Type: text/x-diff, Size: 10671 bytes --]

Added one more approach for data integrity.
Data integrity is performed on two fragmented files.
1. Creating two fragmented files each of size DiskSize/2.
2. Then comapring against the original file.
3. If not equal test case fails.

My ultimate goal in creating fragmented files is that,
1. It creates many extents (fragments for each file)
2. FS code may behave wrong at corner cases which may come into picture after many extents gets added to the file.
3. Data corruption chances are there 
     i. when file metadata updation is not proper(corner cases when fragments are more)
     ii.If write and read is not matching (write operation might have updated the block number some where and read 
         may skip that block in some corner cases)
4. In reality fragments can occur only after much usage of the disk(create/delete file)
5. This is good test case for bigger size disk.(it can create more extents)
6. fsync() is called after every write, which makes it slow.

Signed_off_by: Jyoti Vantagodi (jyotiv@linux.vnet.ibm.com)

diff -Naurp ltp-full-20090630/testcases/kernel/fs/fs_di/frag.c ltp-full-20090630-new/testcases/kernel/fs/fs_di/frag.c
--- ltp-full-20090630/testcases/kernel/fs/fs_di/frag.c	1970-01-01 05:30:00.000000000 +0530
+++ ltp-full-20090630-new/testcases/kernel/fs/fs_di/frag.c	2009-07-24 11:41:54.000000000 +0530
@@ -0,0 +1,121 @@
+/******************************************************************************/
+/*                                                                            */
+/* Copyright (c) International Business Machines  Corp., 2009                 */
+/*                                                                            */
+/* This program is free software;  you can redistribute it and/or modify      */
+/* it under the terms of the GNU General Public License as published by       */
+/* the Free Software Foundation; either version 2 of the License, or          */
+/* (at your option) any later version.                                        */
+/*                                                                            */
+/* This program is distributed in the hope that it will be useful,            */
+/* but WITHOUT ANY WARRANTY;  without even the implied warranty of            */
+/* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See                  */
+/* the GNU General Public License for more details.                           */
+/*                                                                            */
+/* You should have received a copy of the GNU General Public License          */
+/* along with this program;  if not, write to the Free Software               */
+/* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA    */
+/*                                                                            */
+/******************************************************************************/
+
+/******************************************************************************/
+/*                                                                            */
+/* File:        frag.c                                                        */
+/*                                                                            */
+/* Description: This piece of code creates two files, and writes 1k data to   */
+/*              each file in a loop from datafile. Loop continues till it     */
+/*              reaches EOF of data file. In a loop fclose is called, to      */
+/*              create fragmented files.                                      */
+/*                                                                            */
+/* Author:      Jyoti Vantagodi jvantago@in.ibm.com                           */
+/*                                                                            */
+/* History:     Created - Jul 22 2009 -  Jyoti Vantagodi jvantago@in.ibm.com  */
+/*                                                                            */
+/******************************************************************************/
+
+#include<stdio.h>
+#include<fcntl.h>
+#include<string.h>
+#include<sys/types.h>
+#include<unistd.h>
+
+FILE *fp_data = NULL;  //File pointer for data file
+FILE *fp_frag1 = NULL; //File pointer for fragmented file 1
+FILE *fp_frag2 = NULL; //File pointer for fragmented file 2
+
+int main(int argc, char *argv[])
+{
+	int bytes_read=0, bytes_written=0, fd1,fd2;
+	char buff[1024],frag_file1[100],frag_file2[100];
+
+	if (argc != 3 )
+   	{
+		printf("Needs to pass two arguments..\n");	
+      		return -1 ;
+   	}
+	fp_data = fopen(argv[1], "r");
+	if(!fp_data)
+	{
+		perror("fopen:");
+		printf("Error opening datafile \n");
+		return 1;
+	}
+	strcpy(frag_file1, argv[2]);
+	strcat(frag_file1, "/frag1");
+
+	strcpy(frag_file2, argv[2]);
+	strcat(frag_file2, "/frag2");
+	do
+	{
+	
+		fp_frag1 = fopen(frag_file1, "a+");
+    		if(!fp_frag1)
+    		{   
+        		printf("Error opening fragfile \n");
+        		return -1;
+    		}			 
+		fp_frag2 = fopen(frag_file2, "a+");
+    		if(!fp_frag2 )
+    		{   
+        		printf("Error opening fragfile \n");
+        		return -1;
+    		}		 
+
+		bytes_read = fread(buff, 1, 1024, fp_data);
+		if( bytes_read < 0)
+		{
+			printf("Error reading data file\n");
+			return -1;
+		}
+                
+		bytes_written = fwrite(buff, 1, bytes_read, fp_frag1);
+		if( bytes_read!= bytes_written)
+		{
+			printf("Error in writing data\n");
+			return -1;
+		}
+
+		bytes_written = fwrite(buff, 1, bytes_read, fp_frag2);
+		if( bytes_read!= bytes_written)
+        	{
+            		printf("Error in writing data\n");
+            		return -1;
+        	}	
+		fd1 = fileno(fp_frag1);
+		fd2 = fileno(fp_frag2);
+
+		fsync(fd1);
+		fsync(fd2);
+		fclose(fp_frag1);
+		fclose(fp_frag2);
+
+                if(bytes_read < 1024)
+		{
+			break;
+		}
+	}while(1);
+	fclose(fp_data);
+	return 0;
+}
+				
+		
diff -Naurp ltp-full-20090630/testcases/kernel/fs/fs_di/fs_di ltp-full-20090630-new/testcases/kernel/fs/fs_di/fs_di
--- ltp-full-20090630/testcases/kernel/fs/fs_di/fs_di	2006-12-09 04:04:00.000000000 +0530
+++ ltp-full-20090630-new/testcases/kernel/fs/fs_di/fs_di	2009-07-24 11:42:21.000000000 +0530
@@ -21,17 +21,24 @@
 #  FILE   : fs_di 
 #
 #  PURPOSE: FileSystem Data Integrity
-#	    Creates a data file of specified or random size and copies 
-#           the file to a random directory depth on a specified filesystem
-#	    The two files are compared and checked for differences. 
-#	    If the files differ, then the test fails. By default, this 
-#	    test creates a 30Mb file and runs for ten loops.
+#	   1. Creates a data file of specified or random size and copies 
+#             the file to a random directory depth on a specified filesystem
+#	      The two files are compared and checked for differences. 
+#	      If the files differ, then the test fails. By default, this 
+#	      test creates a 30Mb file and runs for ten loops.
+#          2. Creates a datafile of size half of the partition size. Creates 
+#             two fragmented files on the specified partition and copies datafile 
+#             to them. Then compares both the fragmented files with datafile. If 
+#             files differ, then test fails.  
+#
 #	               
 #
 #  SETUP: None
 #
 #
 #  HISTORY:
+#    22/07/09 Jyoti Vantagodi (jvantago@in.ibm.com)
+#             Added point two of above PURPOSE 
 #    04/11/05 Robbie Williamson (robbiew@us.ibm.com)
 #      -Written
 #
@@ -59,15 +66,15 @@ usage()
 {
     cat <<-EOF >&2
 
-    usage: ./${0##*/} -d TMPDIR [-h] [-l # of LOOPS ] [-s SIZE in Mb]
+    usage: ./${0##*/} -d TMPDIR [-h] [-l # of LOOPS ] [-s SIZE in Mb][-S partition SIZE in Mb]
 
     -d TMPDIR       Directory where temporary files will be created.
     -h              Help. Prints all available options.
     -l # of LOOPS   The number of times to run the test. Default=10.
     -s SIZE in Mb   The size of the data file to create. Default=30Mb. A "0" means random sizes from 10-500Mb.
+    -S              Size of usable partition (in MBs) on which the testing is carried out
     -v 		    Verbose output.
-
-    example: ./${0##*/} -d /mnt/cifsmount -l 20 -s 100
+    example: ./${0##*/} -d /mnt/cifsmount -l 20 -s 100 -S 200
 
 
 	EOF
@@ -89,6 +96,8 @@ $trace_logic
     if [ "$CLEANUP" = "ON" ]; then
 	rm -rf $TCtmp
 	rm -rf ${TESTFS}
+   	rm -rf $TMPBASE/*
+        rm -f $TCtmp/testfile*
     fi
 
     [ $# = 0 ] && { tst_resm TPASS "Test Successful"; exit 0; }
@@ -110,16 +119,17 @@ $trace_logic
     LOOPS=10
     SIZE=30
     RANDOM_SIZE=0
-    while getopts d:hl:s:v arg
+    DISK_SIZE=0
+    while getopts d:hl:s:S:v arg
     do  
 	case $arg in
 
         d)  # append $$ to TMP, as it is recursively
             # removed at end of script.
-            TMPBASE=$OPTARG
+            export TMPBASE=$OPTARG
             TMP="${TMPBASE}/fs_di-$$"
             export TESTFS="$TMP";;
-
+  
         h)  usage
 	    exit 0;;
    
@@ -134,6 +144,9 @@ $trace_logic
 
 	v)  # Verbose
 	    trace_logic=${trace_logic:-"set -x"};;
+
+        S)  # Size of usable partition, which is used for creating creating the files
+            DISK_SIZE=$OPTARG;;
 	
        \?) usage
 	   exit 0;;
@@ -143,6 +156,12 @@ $trace_logic
       tst_resm TBROK "You must specify the target directory [-d]"
       exit 1
     fi 
+  
+    if [ $DISK_SIZE -eq 0 ]; then
+      tst_resm TBROK "You must specify the disk size [-S]"
+      exit 1
+    fi 
+
     export TST_COUNT=$LOOPS
 
     echo ""
@@ -230,6 +249,46 @@ $trace_logic
 	loopcount=$(( $loopcount + 1 ))
 	tst_resm TINFO "Completed Loop $loopcount"
     done
+	#Create a datafile of size half of the disk size
+	DISK_SIZE=$(( $DISK_SIZE / 2 ))
+	create_datafile $DISK_SIZE $TCtmp/testfile >/dev/null 
+	retval=$?
+        if [ "$retval" != 0 ]; then
+                end_testcase "Error in creating data file"
+        fi
+
+	#Invoke frag to create 2 fragmented files and copy data file to both the files
+	frag $TCtmp/testfile $TMPBASE >/dev/null
+	retval=$?
+        if [ "$retval" != 0 ]; then
+                end_testcase "Error in creating frag files"
+        fi
+
+	tst_resm TINFO "Created fragmented files"
+
+	#Compare both frag files with data file
+	cmp $TCtmp/testfile $TMPBASE/frag1
+	retval=$?
+	if [ "$retval" != 0 ]; then
+		end_testcase "frag1 and datafile are not matching"
+	fi
+	
+	cmp $TCtmp/testfile $TMPBASE/frag2
+	if [ "$retval" != 0 ]; then
+		end_testcase "frag2 and datafile are not matching"
+	fi
+
+	tst_resm TINFO "DataIntegrity test with fragmented files is successful"
+
+	rm -rf $TMPBASE/*
+	rm -f $TCtmp/testfile*
+    
   end_testcase
 

[-- Attachment #3: Type: text/plain, Size: 79 bytes --]

------------------------------------------------------------------------------

[-- Attachment #4: Type: text/plain, Size: 155 bytes --]

_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] Submitting patch

[Michal Simek]

Please fix coding style. Use tab instead of space for indentation.

Thanks,
Michal
> PATCH IS CREATED FOR ltp-full-20090630.
>
> I am submitting a patch to kernel/fs/fs_di
>
> In this file data integity is performed by creating the file at
> different directory depth and then by comparing with original file.
>
> To this I have added one more approach to perform integrity test.
> 1. Creating two fragmented files each of size DiskSize/2.
> 2. Then comapring against the original file.
> 3. If not equal test case fails.
>
> My ultimate goal in creating fragmented files is that,
> 1. It creates many extents (fragments for each file)
> 2. FS code may behave wrong at corner cases which may come into picture
>    after many extents gets added to the file.
> 3. Data corruption chances are there 
>      i. when file metadata updation is not proper (corner cases when fragments are more)
>      ii.If write and read is not matching (write operation might have updated the block 
>         number some where and read may skip that block in some corner cases)
> 4. In reality fragments can occur only after much usage of the disk(create/delete file)
> 5. This is good test case for bigger size disk.(it can create more extents)
>
>
> To: ltp-list@lists.sourceforge.net
> Cc: subrata@linux.vnet.ibm.com
> Bcc: Jyoti <jyotiv@linux.vnet.ibm.com>
> Subject: Submitting patch 
> Reply-To: Jyoti <jyotiv@linux.vnet.ibm.com>
>
>   
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> ------------------------------------------------------------------------
>
> _______________________________________________
> Ltp-list mailing list
> Ltp-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ltp-list


-- 
Michal Simek, Ing. (M.Eng)
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663


------------------------------------------------------------------------------
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] Submitting patch

[Garrett Cooper]

On Fri, Jul 24, 2009 at 11:15 PM, Michal
Simek<michal.simek@petalogix.com> wrote:
> Please fix coding style. Use tab instead of space for indentation.

There is nothing that states that 8-space tabs aren't appropriate in
the kernel.org coding / style guide:
http://www.kernel.org/doc/Documentation/CodingStyle

Please stop saying that tabs are required. 8-space / tabs _are_
required according to the guide.

Please also thoroughly read through the document as it says 80-char
lines are preferred, etc. It does not say they are required.

At the same time though, these guidelines do not necessarily apply to
userland apps, as far as the comment:

"The answer to that is that if you need more than 3 levels of
indentation, you're screwed anyway, and should fix your program."

is concerned. Yes, that's true for kernel code. No it's not
necessarily true for userland apps as more than 3 levels of branches
may be required.

So, in conclusion, yes -- we should try to stick to the kernel.org
coding guidelines, but 1) we are not kernel.org and 2) we're not
producing kernel code, so the coding guidelines may be more of a
shoehorn fit than an appropriate one. It also doesn't apply to
anything beyond C/C++ code.

Mike/Subrata,
    Can we actually write up a style guide for folks to follow that
applies for code, as the kernel.org guidelines don't apply that well
to our circumstances?
Thanks,
-Garrett

>> PATCH IS CREATED FOR ltp-full-20090630.
>>
>> I am submitting a patch to kernel/fs/fs_di
>>
>> In this file data integity is performed by creating the file at
>> different directory depth and then by comparing with original file.
>>
>> To this I have added one more approach to perform integrity test.
>> 1. Creating two fragmented files each of size DiskSize/2.
>> 2. Then comapring against the original file.
>> 3. If not equal test case fails.
>>
>> My ultimate goal in creating fragmented files is that,
>> 1. It creates many extents (fragments for each file)
>> 2. FS code may behave wrong at corner cases which may come into picture
>>    after many extents gets added to the file.
>> 3. Data corruption chances are there
>>      i. when file metadata updation is not proper (corner cases when fragments are more)
>>      ii.If write and read is not matching (write operation might have updated the block
>>         number some where and read may skip that block in some corner cases)
>> 4. In reality fragments can occur only after much usage of the disk(create/delete file)
>> 5. This is good test case for bigger size disk.(it can create more extents)

------------------------------------------------------------------------------
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] Submitting patch

[Michal Simek]

Hi Garrett,
> On Fri, Jul 24, 2009 at 11:15 PM, Michal
> Simek<michal.simek@petalogix.com> wrote:
>   
>> Please fix coding style. Use tab instead of space for indentation.
>>     
>
>   
You wrote nice email and I have to react on it.

> There is nothing that states that 8-space tabs aren't appropriate in
> the kernel.org coding / style guide:
> http://www.kernel.org/doc/Documentation/CodingStyle
>
> Please stop saying that tabs are required. 8-space / tabs _are_
> required according to the guide.
>   
I invest a lot of time to fix testcases/kernel/syscalls. I used there
tabs instead of spaces.
You can use what you want but please keep in your mind.
There should be one coding style for all source code. (for C, C++,
Makefile, etc)

If you want to use spaces instead of tab and you hate tab you can of course.
I expect that if you replaced all tabs in every C code ltp code will
grow up.
I am not sure if only this change help anybody.

IMHO use one tab instead of 8 spaces make more sense.

> Please also thoroughly read through the document as it says 80-char
> lines are preferred, etc. It does not say they are required.
>   
There is not possible to have 80-char lines for every file but if you
can use 80-chars line -
you should do it. For large function is not possible to do it. If your
function is large you should
start to think how others will read it.
> At the same time though, these guidelines do not necessarily apply to
> userland apps, as far as the comment:
>
> "The answer to that is that if you need more than 3 levels of
> indentation, you're screwed anyway, and should fix your program."
>
> is concerned. Yes, that's true for kernel code. No it's not
> necessarily true for userland apps as more than 3 levels of branches
> may be required.
>
> So, in conclusion, yes -- we should try to stick to the kernel.org
> coding guidelines, but 1) we are not kernel.org and 2) we're not
> producing kernel code, so the coding guidelines may be more of a
> shoehorn fit than an appropriate one. It also doesn't apply to
> anything beyond C/C++ code.
>   
Really? But you should look at patches how they looks like. Code don't have
any style. If is preferable style for Cisco - it is your problem not
mine. Your code
present you and your coding style too. LTP contains a lot of code and I
thought
that will be good to clear.

Anyway this bring me up only troubles nothing else.
It is up to Subrata what coding style/patches wants.
I won't spend my time on cleaning LTP or disturb people.

> Mike/Subrata,
>     Can we actually write up a style guide for folks to follow that
> applies for code, as the kernel.org guidelines don't apply that well
> to our circumstances?
>   
> Thanks,
> -Garrett
>   
Thanks for your email -> it save me a lot of time for future.

Enjoy your day,
Michal


>   
>>> PATCH IS CREATED FOR ltp-full-20090630.
>>>
>>> I am submitting a patch to kernel/fs/fs_di
>>>
>>> In this file data integity is performed by creating the file at
>>> different directory depth and then by comparing with original file.
>>>
>>> To this I have added one more approach to perform integrity test.
>>> 1. Creating two fragmented files each of size DiskSize/2.
>>> 2. Then comapring against the original file.
>>> 3. If not equal test case fails.
>>>
>>> My ultimate goal in creating fragmented files is that,
>>> 1. It creates many extents (fragments for each file)
>>> 2. FS code may behave wrong at corner cases which may come into picture
>>>    after many extents gets added to the file.
>>> 3. Data corruption chances are there
>>>      i. when file metadata updation is not proper (corner cases when fragments are more)
>>>      ii.If write and read is not matching (write operation might have updated the block
>>>         number some where and read may skip that block in some corner cases)
>>> 4. In reality fragments can occur only after much usage of the disk(create/delete file)
>>> 5. This is good test case for bigger size disk.(it can create more extents)
>>>       


-- 
Michal Simek, Ing. (M.Eng)
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663


------------------------------------------------------------------------------
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] Submitting patch

[Subrata Modak]

On Mon, 2009-07-27 at 11:29 +0200, Michal Simek wrote: 
> Hi Garrett,
> > On Fri, Jul 24, 2009 at 11:15 PM, Michal
> > Simek<michal.simek@petalogix.com> wrote:
> >   
> >> Please fix coding style. Use tab instead of space for indentation.
> >>     
> >
> >   
> You wrote nice email and I have to react on it.
> 
> > There is nothing that states that 8-space tabs aren't appropriate in
> > the kernel.org coding / style guide:
> > http://www.kernel.org/doc/Documentation/CodingStyle
> >
> > Please stop saying that tabs are required. 8-space / tabs _are_
> > required according to the guide.
> >   
> I invest a lot of time to fix testcases/kernel/syscalls. I used there
> tabs instead of spaces.
> You can use what you want but please keep in your mind.
> There should be one coding style for all source code. (for C, C++,
> Makefile, etc)
> 
> If you want to use spaces instead of tab and you hate tab you can of course.
> I expect that if you replaced all tabs in every C code ltp code will
> grow up.
> I am not sure if only this change help anybody.
> 
> IMHO use one tab instead of 8 spaces make more sense.
> 
> > Please also thoroughly read through the document as it says 80-char
> > lines are preferred, etc. It does not say they are required.
> >   
> There is not possible to have 80-char lines for every file but if you
> can use 80-chars line -
> you should do it. For large function is not possible to do it. If your
> function is large you should
> start to think how others will read it.
> > At the same time though, these guidelines do not necessarily apply to
> > userland apps, as far as the comment:
> >
> > "The answer to that is that if you need more than 3 levels of
> > indentation, you're screwed anyway, and should fix your program."
> >
> > is concerned. Yes, that's true for kernel code. No it's not
> > necessarily true for userland apps as more than 3 levels of branches
> > may be required.
> >
> > So, in conclusion, yes -- we should try to stick to the kernel.org
> > coding guidelines, but 1) we are not kernel.org and 2) we're not
> > producing kernel code, so the coding guidelines may be more of a
> > shoehorn fit than an appropriate one. It also doesn't apply to
> > anything beyond C/C++ code.
> >   
> Really? But you should look at patches how they looks like. Code don't have
> any style. If is preferable style for Cisco - it is your problem not
> mine. Your code
> present you and your coding style too. LTP contains a lot of code and I
> thought
> that will be good to clear.
> 
> Anyway this bring me up only troubles nothing else.
> It is up to Subrata what coding style/patches wants.

We indeed need coding styles for LTP. Let take this up once and all
after the release.

Regards--
Subrata

> I won't spend my time on cleaning LTP or disturb people.
> 
> > Mike/Subrata,
> >     Can we actually write up a style guide for folks to follow that
> > applies for code, as the kernel.org guidelines don't apply that well
> > to our circumstances?
> >   
> > Thanks,
> > -Garrett
> >   
> Thanks for your email -> it save me a lot of time for future.
> 
> Enjoy your day,
> Michal
> 
> 
> >   
> >>> PATCH IS CREATED FOR ltp-full-20090630.
> >>>
> >>> I am submitting a patch to kernel/fs/fs_di
> >>>
> >>> In this file data integity is performed by creating the file at
> >>> different directory depth and then by comparing with original file.
> >>>
> >>> To this I have added one more approach to perform integrity test.
> >>> 1. Creating two fragmented files each of size DiskSize/2.
> >>> 2. Then comapring against the original file.
> >>> 3. If not equal test case fails.
> >>>
> >>> My ultimate goal in creating fragmented files is that,
> >>> 1. It creates many extents (fragments for each file)
> >>> 2. FS code may behave wrong at corner cases which may come into picture
> >>>    after many extents gets added to the file.
> >>> 3. Data corruption chances are there
> >>>      i. when file metadata updation is not proper (corner cases when fragments are more)
> >>>      ii.If write and read is not matching (write operation might have updated the block
> >>>         number some where and read may skip that block in some corner cases)
> >>> 4. In reality fragments can occur only after much usage of the disk(create/delete file)
> >>> 5. This is good test case for bigger size disk.(it can create more extents)
> >>>       
> 
> 
> -- 
> Michal Simek, Ing. (M.Eng)
> PetaLogix - Linux Solutions for a Reconfigurable World
> w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Ltp-list mailing list
> Ltp-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ltp-list


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] Submitting patch

[Cyril Hrubis]

Hi,
> We indeed need coding styles for LTP. Let take this up once and all
> after the release.

What's wrong with linux kernel coding style? Most of the decent text editors
that are used these days (vim, emacs...) just helps format code like this. (Eg.
default intendation is done by tabs and so on...) I don't like the idea
changing tabs to spaces before sending a patch.

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] Submitting patch

[Cyril Hrubis]

Hi!
> > What's wrong with linux kernel coding style? Most of the decent text editors
> > that are used these days (vim, emacs...) just helps format code like this. (Eg.
> > default intendation is done by tabs and so on...) I don't like the idea
> > changing tabs to spaces before sending a patch.
>
> There is only one thing which is IMHO not good - it is 80 char line size.
> I would prefer longer lines (maybe 120 chars).
> This is for C code not for any other.
> Are you ok with it?

Well, I'm not happy with very long lines, but there are indeed circumstances
where long lines are best solution.

So may be this should be strong recomendation rather than rule.

> P.S.: Cyril: Are you from Czech?

Sure.

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] Submitting patch

[Subrata Modak]

Hi Michal/Garret/all,

On Tue, 2009-08-04 at 10:37 +0200, Michal Simek wrote:
> Garrett Cooper wrote:
> > On Mon, Aug 3, 2009 at 7:46 AM, Michal Simek<michal.simek@petalogix.com> wrote:
> >   
> >> Cyril Hrubis wrote:
> >>     
> >>> Hi!
> >>>
> >>>       
> >>>>> What's wrong with linux kernel coding style? Most of the decent text editors
> >>>>> that are used these days (vim, emacs...) just helps format code like this. (Eg.
> >>>>> default intendation is done by tabs and so on...) I don't like the idea
> >>>>> changing tabs to spaces before sending a patch.
> >>>>>
> >>>>>           
> >>>> There is only one thing which is IMHO not good - it is 80 char line size.
> >>>> I would prefer longer lines (maybe 120 chars).
> >>>> This is for C code not for any other.
> >>>> Are you ok with it?
> >>>>
> >>>>         
> >>> Well, I'm not happy with very long lines, but there are indeed circumstances
> >>> where long lines are best solution.
> >>>
> >>>       
> >> I am not happy with it too but there are some cases where is really ugly
> >> to have 80chars lines.
> >>     
> >
> > IMHO 95% of the time you can get away with shorter lines with
> > different constructs or more clever indentation. 
> I don't want to do any clever indentation. This discuss is again and
> again the same!!!
> 
> I vote for standard linux indentation - tab (size 8 chars) for whole C code.
> Follow linux kernel coding style for whole C code. As we discussed in
> this thread 80 chars line are strongly recommended.
> For checking C source code use checkpatch.pl script which is in linux
> kernel before sending patches to mailing list
> and of course checking patches before applying.
> 

Yes, checkpatch.pl for C code patches.

> Cyril, Mike, Subrata and others: Can you send us your opinion? I don't
> want to spend my time with discuss about it.
> 
> I am not interested in any other code that's why I don't write any
> comment to it.
> You can choose what you want. Of course if is similar utility like
> checkpatch.pl it will be good to use it and not to check
> it by hand.
> 
> Subrata can we please write output from this discussion to web / doc
> somewhere?
> 

I will do that soon.

> Thanks,
> Michal
> 
> 
> > Take for example what
> > I just did with delete_module* -- now that was a mess to cleanup, but
> > quick nonetheless and necessary:
> > http://ltp.cvs.sourceforge.net/viewvc/ltp/ltp/testcases/kernel/module/delete_module/delete_module01.c?view=log&pathrev=makefile_infra_rework
> > , http://ltp.cvs.sourceforge.net/viewvc/ltp/ltp/testcases/kernel/module/delete_module/delete_module02.c?view=log&pathrev=makefile_infra_rework
> > , http://ltp.cvs.sourceforge.net/viewvc/ltp/ltp/testcases/kernel/module/delete_module/delete_module03.c?view=log&pathrev=makefile_infra_rework
> >
> > We should aim for 80 column lines wherever possible because it's the
> > defacto standard, and where we can't do that (and there are a handful
> > of areas with shell code and Makefile code where I couldn't without
> > changing the meaning of the message I was trying to convey), we should
> > go over 80 cols.
> >
> > At least that's how every project I know has done it.
> >
> > General rules of thumb for shell / python / perl code (from dealing
> > with other projects) was 4 space indents. Perl tends to go whacky
> > though because of all of the different ways to express constructs
> > though xD.

Again, checkpatch.pl for non-C code as well. But, need to carefully
review the errors it will generate for non-C code like the Makefiles,
perl, shell, python, etc.

Garret,

Can you please come up with a list of exceptions for
     1. line length,
     2. tab length,
     3. etc

for non-C code like the perl, Makefiles, etc. I would then document them
all.

Regards--
Subrata

> >
> > Thanks!
> > -Garrett
> >   
> 
> 


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] Submitting patch

[Garrett Cooper]

Hi Michal,
    I want to straighten out some points before we get too deep into this topic:

On Mon, Jul 27, 2009 at 2:29 AM, Michal Simek<michal.simek@petalogix.com> wrote:
> Hi Garrett,
>> On Fri, Jul 24, 2009 at 11:15 PM, Michal
>> Simek<michal.simek@petalogix.com> wrote:
>>
>>> Please fix coding style. Use tab instead of space for indentation.
>>>
>>
>>
> You wrote nice email and I have to react on it.

Thanks :). My intent wasn't to slam your idea, and I don't argue the
fact that we need a standard. It's just that whatever we use should be
a smart standard for what we're coding.

For instance, tabs / 8-space tabs don't make any sense for python code
as the implied defacto standard is 4 spaces per indent, and python
requires a certain degree of indentation.

My personal background and experience comes from the following
[style(9) from FreeBSD], where readability is compromised with a
respect for `space real estate' (from style(9) --
http://www.freebsd.org/cgi/man.cgi?query=style&apropos=0&sektion=0&manpath=FreeBSD+7.2-RELEASE
):

     Indentation is an 8 character tab.  Second level indents are four spaces.
     If you have to wrap a long statement, put the operator at the end of the
     line.

	     while (cnt < 20 && this_variable_name_is_too_long &&
		 ep != NULL)
		     z = a + really + long + statement + that + needs +
			 two + lines + gets + indented + four + spaces +
			 on + the + second + and + subsequent + lines;

     Do not add whitespace at the end of a line, and only use tabs followed by
     spaces to form the indentation.  Do not use more spaces than a tab will
     produce and do not use spaces in front of tabs.

     Closing and opening braces go on the same line as the else.  Braces that
     are not necessary may be left out.

which does conflict with the style guide from kernel.org. Then again
kernel.org is maintains almost purely kernel code, in which the tabs /
8-space tabs make perfect sense as the logic and branching should be
small.

>> There is nothing that states that 8-space tabs aren't appropriate in
>> the kernel.org coding / style guide:
>> http://www.kernel.org/doc/Documentation/CodingStyle
>>
>> Please stop saying that tabs are required. 8-space / tabs _are_
>> required according to the guide.
>>
> I invest a lot of time to fix testcases/kernel/syscalls. I used there
> tabs instead of spaces.
> You can use what you want but please keep in your mind.
> There should be one coding style for all source code. (for C, C++,
> Makefile, etc)
>
> If you want to use spaces instead of tab and you hate tab you can of course.
> I expect that if you replaced all tabs in every C code ltp code will
> grow up.
> I am not sure if only this change help anybody.
>
> IMHO use one tab instead of 8 spaces make more sense.

By and large, I would agree, but tab's really muck up reviewing diffs
too -- so as long as it's consistent should be used.

>> Please also thoroughly read through the document as it says 80-char
>> lines are preferred, etc. It does not say they are required.
>>
> There is not possible to have 80-char lines for every file but if you
> can use 80-chars line -
> you should do it. For large function is not possible to do it. If your
> function is large you should
> start to think how others will read it.
>> At the same time though, these guidelines do not necessarily apply to
>> userland apps, as far as the comment:
>>
>> "The answer to that is that if you need more than 3 levels of
>> indentation, you're screwed anyway, and should fix your program."
>>
>> is concerned. Yes, that's true for kernel code. No it's not
>> necessarily true for userland apps as more than 3 levels of branches
>> may be required.
>>
>> So, in conclusion, yes -- we should try to stick to the kernel.org
>> coding guidelines, but 1) we are not kernel.org and 2) we're not
>> producing kernel code, so the coding guidelines may be more of a
>> shoehorn fit than an appropriate one. It also doesn't apply to
>> anything beyond C/C++ code.
>>
> Really? But you should look at patches how they looks like. Code don't have
> any style. If is preferable style for Cisco - it is your problem not
> mine. Your code
> present you and your coding style too. LTP contains a lot of code and I
> thought
> that will be good to clear.

Cisco code (as far as I can tell) lacks any form of style and is a
bloody hodgepodge of whatever the developer thought was best without
any form of structure, and I hate reading it ;)...

I'm fine matching my style to whatever the standard is, but we need to
decide upon a standard before we go touting that we should do it in
any particular format -- otherwise we'll confuse folks :)...

> Anyway this bring me up only troubles nothing else.
> It is up to Subrata what coding style/patches wants.
> I won't spend my time on cleaning LTP or disturb people.

Your energies are much appreciated, so please don't be discouraged by
what I'm saying too much -- I'm just suggesting that we follow
whatever Subrata / Mike decide is the standard for the project. Once
that's done, we can start cleaning up big time (and I'll gladly help);
style is important, along with documentation and usability... if one
of these points is lacking, it's generally a pain for either the end
user or a developer picking up the code later :)...

>> Mike/Subrata,
>>     Can we actually write up a style guide for folks to follow that
>> applies for code, as the kernel.org guidelines don't apply that well
>> to our circumstances?
>>
> Thanks for your email -> it save me a lot of time for future.

No problem -- let's solve the problem once the big cheeses decide
what's best :).

>>>> PATCH IS CREATED FOR ltp-full-20090630.
>>>>
>>>> I am submitting a patch to kernel/fs/fs_di
>>>>
>>>> In this file data integity is performed by creating the file at
>>>> different directory depth and then by comparing with original file.
>>>>
>>>> To this I have added one more approach to perform integrity test.
>>>> 1. Creating two fragmented files each of size DiskSize/2.
>>>> 2. Then comapring against the original file.
>>>> 3. If not equal test case fails.
>>>>
>>>> My ultimate goal in creating fragmented files is that,
>>>> 1. It creates many extents (fragments for each file)
>>>> 2. FS code may behave wrong at corner cases which may come into picture
>>>>    after many extents gets added to the file.
>>>> 3. Data corruption chances are there
>>>>      i. when file metadata updation is not proper (corner cases when fragments are more)
>>>>      ii.If write and read is not matching (write operation might have updated the block
>>>>         number some where and read may skip that block in some corner cases)
>>>> 4. In reality fragments can occur only after much usage of the disk(create/delete file)
>>>> 5. This is good test case for bigger size disk.(it can create more extents)

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

[LTP] Submitting patch

[Jyoti]

[-- Attachment #1: Type: text/plain, Size: 152 bytes --]

Hello,

The attached patch adds one more way of testing dataitegrity of files.
The data integrity test is performed on fragmented files.

Thanks,
Jyoti

[-- Attachment #2: fs_di.patch --]
[-- Type: text/x-diff, Size: 11239 bytes --]

Added one more approach for data integrity.
Data integrity is performed on two fragmented files.
1. Creating two fragmented files each of size DiskSize/2.
2. Then comapring against the original file.
3. If not equal test case fails.

My ultimate goal in creating fragmented files is that,
1. It creates many extents (fragments for each file)
2. FS code may behave wrong at corner cases which may come into picture after many extents gets added to the file.
3. Data corruption chances are there
     i. when file metadata updation is not proper(corner cases when fragments are more)
     ii.If write and read is not matching (write operation might have updated the block number some where and read
         may skip that block in some corner cases)
4. In reality fragments can occur only after much usage of the disk(create/delete file)
5. This is good test case for bigger size disk.(it can create more extents)
6. fsync() is called after every write, which makes it slow.

Signed-off-by: Jyoti Vantagodi <jyotiv@linux.vnet.ibm.com>
---

diff -Naurp ltp-full-20090630/testcases/kernel/fs/fs_di/frag.c ltp-full-20090630-final/testcases/kernel/fs/fs_di/frag.c
--- ltp-full-20090630/testcases/kernel/fs/fs_di/frag.c	1970-01-01 05:30:00.000000000 +0530
+++ ltp-full-20090630-final/testcases/kernel/fs/fs_di/frag.c	2009-07-30 14:20:33.962944167 +0530
@@ -0,0 +1,109 @@
+/******************************************************************************/
+/*                                                                            */
+/* Copyright (c) International Business Machines  Corp., 2009                 */
+/*                                                                            */
+/* This program is free software;  you can redistribute it and/or modify      */
+/* it under the terms of the GNU General Public License as published by       */
+/* the Free Software Foundation; either version 2 of the License, or          */
+/* (at your option) any later version.                                        */
+/*                                                                            */
+/* This program is distributed in the hope that it will be useful,            */
+/* but WITHOUT ANY WARRANTY;  without even the implied warranty of            */
+/* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See                  */
+/* the GNU General Public License for more details.                           */
+/*                                                                            */
+/* You should have received a copy of the GNU General Public License          */
+/* along with this program;  if not, write to the Free Software               */
+/* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA    */
+/*                                                                            */
+/******************************************************************************/
+
+/******************************************************************************/
+/*                                                                            */
+/* File:        frag.c                                                        */
+/*                                                                            */
+/* Description: This piece of code creates two files, and writes 1k data to   */
+/*              each file in a loop from datafile. Loop continues till it     */
+/*              reaches EOF of data file. In a loop fsync, fclose is called,  */
+/*              to create fragmented files.                                   */
+/*                                                                            */
+/* Author:      Jyoti Vantagodi jyotiv@linux.vnet.ibm.com                     */
+/*                                                                            */
+/* History:     Created-Jul 22 2009-Jyoti Vantagodi jyotiv@linux.vnet.ibm.com */
+/*                                                                            */
+/******************************************************************************/
+
+#include<stdio.h>
+#include<fcntl.h>
+#include<string.h>
+#include<sys/types.h>
+#include<unistd.h>
+
+FILE *fp_data;  /* File pointer for data file */
+FILE *fp_frag1; /* File pointer for fragmented file 1 */
+FILE *fp_frag2; /* File pointer for fragmented file 2 */
+
+int main(int argc, char *argv[])
+{
+	int bytes_read = 0, bytes_written = 0, fd1 = -1, fd2 = -1;
+	char buff[1024], frag_file1[100], frag_file2[100];
+
+	if (argc != 3) {
+		printf("Needs to pass two arguments..\n");
+		return -1;
+	}
+	fp_data = fopen(argv[1], "r");
+	if (!fp_data) {
+		perror("fopen:");
+		printf("Error opening datafile \n");
+		return 1;
+	}
+	strcpy(frag_file1, argv[2]);
+	strcat(frag_file1, "/frag1");
+
+	strcpy(frag_file2, argv[2]);
+	strcat(frag_file2, "/frag2");
+	do {
+		fp_frag1 = fopen(frag_file1, "a+");
+		if (!fp_frag1) {
+			printf("Error opening fragfile \n");
+			return -1;
+		}
+		fp_frag2 = fopen(frag_file2, "a+");
+		if (!fp_frag2) {
+			printf("Error opening fragfile \n");
+			perror("fwrite:");
+			return -1;
+		}
+		bytes_read = fread(buff, 1, 1024, fp_data);
+		if (bytes_read < 0) {
+			printf("Error reading data file\n");
+			perror("fread:");
+			return -1;
+		}
+		bytes_written = fwrite(buff, 1, bytes_read, fp_frag1);
+		if (bytes_read != bytes_written) {
+			printf("Error in writing data\n");
+			perror("fwrite:");
+			return -1;
+		}
+		bytes_written = fwrite(buff, 1, bytes_read, fp_frag2);
+		if (bytes_read != bytes_written) {
+			printf("Error in writing data\n");
+			perror("fwrite:");
+			return -1;
+		}
+		fd1 = fileno(fp_frag1);
+		fd2 = fileno(fp_frag2);
+
+		fsync(fd1);
+		fsync(fd2);
+		fclose(fp_frag1);
+		fclose(fp_frag2);
+
+		if (bytes_read < 1024)
+			break;
+	} while (1);
+	fclose(fp_data);
+	return 0;
+}
diff -Naurp ltp-full-20090630/testcases/kernel/fs/fs_di/fs_di ltp-full-20090630-final/testcases/kernel/fs/fs_di/fs_di
--- ltp-full-20090630/testcases/kernel/fs/fs_di/fs_di	2006-12-09 04:04:00.000000000 +0530
+++ ltp-full-20090630-final/testcases/kernel/fs/fs_di/fs_di	2009-07-30 14:24:52.886255358 +0530
@@ -18,20 +18,25 @@
 #
 #
 #
-#  FILE   : fs_di 
+#  FILE   : fs_di
 #
 #  PURPOSE: FileSystem Data Integrity
-#	    Creates a data file of specified or random size and copies 
-#           the file to a random directory depth on a specified filesystem
-#	    The two files are compared and checked for differences. 
-#	    If the files differ, then the test fails. By default, this 
-#	    test creates a 30Mb file and runs for ten loops.
-#	               
+#	   1. Creates a data file of specified or random size and copies
+#         the file to a random directory depth on a specified filesystem
+#	      The two files are compared and checked for differences.
+#	      If the files differ, then the test fails. By default, this
+#	      test creates a 30Mb file and runs for ten loops.
+#      2. Creates a datafile of size half of the partition size. Creates
+#         two fragmented files on the specified partition and copies datafile
+#         to them. Then compares both the fragmented files with datafile. If
+#         files differ, then test fails.
 #
 #  SETUP: None
 #
 #
 #  HISTORY:
+#    28/07/09 Jyoti Vantagodi (jyotiv@linux.vnet.ibm.com)
+#             Added point two of above PURPOSE
 #    04/11/05 Robbie Williamson (robbiew@us.ibm.com)
 #      -Written
 #
@@ -59,17 +64,18 @@ usage()
 {
     cat <<-EOF >&2
 
-    usage: ./${0##*/} -d TMPDIR [-h] [-l # of LOOPS ] [-s SIZE in Mb]
+    usage: ./${0##*/} -d TMPDIR [-h] [-l # of LOOPS ] [-s SIZE in Mb][-S partition SIZE in Mb]
 
     -d TMPDIR       Directory where temporary files will be created.
     -h              Help. Prints all available options.
     -l # of LOOPS   The number of times to run the test. Default=10.
     -s SIZE in Mb   The size of the data file to create. Default=30Mb. A "0" means random sizes from 10-500Mb.
-    -v 		    Verbose output.
-
+    -S SIZE in Mb   Size of usable partition (in MBs) on which the testing is carried out (needs to be passed
+                    for fragmented file test)
+    -v              Verbose output.
+    example: ./${0##*/} -d /mnt/cifsmount -l 20 -s 100 -S 200
     example: ./${0##*/} -d /mnt/cifsmount -l 20 -s 100
 
-
 	EOF
 exit 0
 }
@@ -89,6 +95,8 @@ $trace_logic
     if [ "$CLEANUP" = "ON" ]; then
 	rm -rf $TCtmp
 	rm -rf ${TESTFS}
+   	rm -rf $TMPBASE/*
+        rm -f $TCtmp/testfile*
     fi
 
     [ $# = 0 ] && { tst_resm TPASS "Test Successful"; exit 0; }
@@ -110,16 +118,16 @@ $trace_logic
     LOOPS=10
     SIZE=30
     RANDOM_SIZE=0
-    while getopts d:hl:s:v arg
-    do  
+    DISK_SIZE=0
+    while getopts d:hl:s:S:v arg
+    do
 	case $arg in
 
         d)  # append $$ to TMP, as it is recursively
             # removed at end of script.
-            TMPBASE=$OPTARG
+            export TMPBASE=$OPTARG
             TMP="${TMPBASE}/fs_di-$$"
             export TESTFS="$TMP";;
-
         h)  usage
 	    exit 0;;
    
@@ -130,10 +138,13 @@ $trace_logic
             SIZE=$OPTARG
 	    if [ $SIZE -eq 0 ]; then
               RANDOM_SIZE=1
-	    fi;;	
+	    fi;;
 
 	v)  # Verbose
 	    trace_logic=${trace_logic:-"set -x"};;
+
+        S)  # Size of usable partition, which is used for creating creating the files
+            DISK_SIZE=$OPTARG;;
 	
        \?) usage
 	   exit 0;;
@@ -142,7 +153,8 @@ $trace_logic
     if [ $TMPBASE = "0" ]; then
       tst_resm TBROK "You must specify the target directory [-d]"
       exit 1
-    fi 
+    fi
+
     export TST_COUNT=$LOOPS
 
     echo ""
@@ -184,12 +196,12 @@ $trace_logic
               SIZE=$RANDOM
               let "SIZE %= 500"
  	    done
-        fi
+      	fi
   	create_datafile $SIZE $TCtmp/testfile >/dev/null
 	  if [ $? != 0 ]; then
 		end_testcase "Could not create testfile of size ${SIZE}Mb"
 	  fi
-	RANDOM_DEPTH=$RANDOM 
+	RANDOM_DEPTH=$RANDOM
 	let "RANDOM_DEPTH %= 500"
 
 	RANDOM_LENGTH=$RANDOM
@@ -230,6 +242,39 @@ $trace_logic
 	loopcount=$(( $loopcount + 1 ))
 	tst_resm TINFO "Completed Loop $loopcount"
     done
-  end_testcase
+    if [ "$DISK_SIZE" != 0 ]; then
+    #Create a datafile of size half of the disk size
+    tst_resm TINFO "Creating fragmented files. Please wait..."
+    DISK_SIZE=$(( $DISK_SIZE / 2 ))
+	if [ "$DISK_SIZE" == 0 ]; then
+		DISK_SIZE=1
+	fi
+    create_datafile $DISK_SIZE $TCtmp/testfile >/dev/null
+    retval=$?
+    if [ "$retval" != 0 ]; then
+        end_testcase "Error in creating data file"
+    fi
 
+    #Invoke frag to create 2 fragmented files and copy data file to both the files
+    frag $TCtmp/testfile $TMPBASE
+    retval=$?
+    if [ "$retval" != 0 ]; then
+        end_testcase "Error in creating frag files"
+    fi
+    tst_resm TINFO "Created fragmented files"
 
+    #Compare both frag files with data file
+    cmp $TCtmp/testfile $TMPBASE/frag1
+    retval=$?
+    if [ "$retval" != 0 ]; then
+        end_testcase "frag1 and datafile are not matching"
+    fi
+    if [ "$retval" != 0 ]; then
+       end_testcase "frag2 and datafile are not matching"
+    fi
+
+    tst_resm TINFO "Completed test with fragmented files"
+	rm -rf $TMPBASE/*
+	rm -f $TCtmp/testfile*
+    fi
+end_testcase

[-- Attachment #3: Type: text/plain, Size: 355 bytes --]

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

[-- Attachment #4: Type: text/plain, Size: 155 bytes --]

_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] Submitting patch

[Subrata Modak]

On Wed, 2009-08-05 at 14:30 +0530, Jyoti wrote:
> Hello,

Please change the subject line accordingly. It should reflect the patch
you are submitting.

Regards--
Subrata

> 
> The attached patch adds one more way of testing dataitegrity of files.
> The data integrity test is performed on fragmented files.
> 
> Thanks,
> Jyoti


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list