From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cn.fujitsu.com ([59.151.112.132]:41087 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1750799AbaLQFT6 (ORCPT ); Wed, 17 Dec 2014 00:19:58 -0500 Message-ID: <549111AB.60108@cn.fujitsu.com> Date: Wed, 17 Dec 2014 13:16:27 +0800 From: Xiaoguang Wang MIME-Version: 1.0 Subject: Re: [PATCH] ext4/004: add dump/restore test References: <1416910869-28538-1-git-send-email-wangxg.fnst@cn.fujitsu.com> <20141206214040.GA27484@thunk.org> <54850290.2070201@cn.fujitsu.com> <20141216025827.GO17575@thunk.org> In-Reply-To: <20141216025827.GO17575@thunk.org> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Sender: fstests-owner@vger.kernel.org To: Theodore Ts'o Cc: fstests@vger.kernel.org, linux-ext4@vger.kernel.org, Dave Chinner List-ID: Hi, On 12/16/2014 10:58 AM, Theodore Ts'o wrote: > On Mon, Dec 08, 2014 at 09:44:48AM +0800, Xiaoguang Wang wrote: >> >> Yeah, my intent is to test dump/restore program, and indeed I imitate that >> how xfs to test xfsdump/xfsrestore, xfs puts xfsdump/xfsrestore tests in >> corresponding xfs directory. > > I'm finding that the test takes 6-7 minutes to run, partially because > it's writing close to half a gigabyte worth of data for the > dump/restore. Is this really necessary? Can we perhaps cut down the > amount of data generated by running fsstress? The time to run the > full set of tests is taking longer and longer, and one answer might be > that for tests that are irrelevant for kernel and which take a long > time, I'll just supress them in my test runs. But maybe we can just > significantly cut back the amount of data to be backed up and > restored? How much do we really need to create in order for you to > feel that you've adequately tested dump/restore? I choose to make a 512MB file system and the arguments "-z -f creat=5 -f write=20 -f mkdir=5 -n 1000 -p 15" is to make sure that the dump operation would be against a full file system. I have read your patch "ext4/004: limit the amount of data written so test runs faster", it looks OK to me, sorry for the bothering. > > And I'll note that using the current fsstress arguments, you are only > creating regular files and directories, and there are no symlinks, > device nodes, or FIFO's being created to test whether those files are > correctly being backed up and restored. Yeah, I skipped these special files deliberately. Originally I used the arguments "-n 1000 -p 15". In RHEL7.0GA, restore tool will trigger a segmentation fault, the call trace is: --------------------------------------------------------------------- Program terminated with signal 11, Segmentation fault. #0 0x000000000040df24 in readxattr () ... (gdb) bt #0 0x000000000040df24 in readxattr () #1 0x000000000040e160 in extractattr () #2 0x000000000040e4e2 in extractfile () #3 0x00000000004097b0 in createleaves () #4 0x0000000000403ae6 in main () --------------------------------------------------------------------- The dump/restore version is 0.4b44, which is already latest. I have sent a bug report to Stelian Pop, maintainer of dump/restore. Later if this issue is fixed, I'll send patch to improve this 004 case, let it handle types of files, sorry. Regards, Xiaoguang Wang > > Cheers, > > - Ted > . > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Xiaoguang Wang Subject: Re: [PATCH] ext4/004: add dump/restore test Date: Wed, 17 Dec 2014 13:16:27 +0800 Message-ID: <549111AB.60108@cn.fujitsu.com> References: <1416910869-28538-1-git-send-email-wangxg.fnst@cn.fujitsu.com> <20141206214040.GA27484@thunk.org> <54850290.2070201@cn.fujitsu.com> <20141216025827.GO17575@thunk.org> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: , , Dave Chinner To: "Theodore Ts'o" Return-path: Received: from cn.fujitsu.com ([59.151.112.132]:41087 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1750799AbaLQFT6 (ORCPT ); Wed, 17 Dec 2014 00:19:58 -0500 In-Reply-To: <20141216025827.GO17575@thunk.org> Sender: linux-ext4-owner@vger.kernel.org List-ID: Hi, On 12/16/2014 10:58 AM, Theodore Ts'o wrote: > On Mon, Dec 08, 2014 at 09:44:48AM +0800, Xiaoguang Wang wrote: >> >> Yeah, my intent is to test dump/restore program, and indeed I imitate that >> how xfs to test xfsdump/xfsrestore, xfs puts xfsdump/xfsrestore tests in >> corresponding xfs directory. > > I'm finding that the test takes 6-7 minutes to run, partially because > it's writing close to half a gigabyte worth of data for the > dump/restore. Is this really necessary? Can we perhaps cut down the > amount of data generated by running fsstress? The time to run the > full set of tests is taking longer and longer, and one answer might be > that for tests that are irrelevant for kernel and which take a long > time, I'll just supress them in my test runs. But maybe we can just > significantly cut back the amount of data to be backed up and > restored? How much do we really need to create in order for you to > feel that you've adequately tested dump/restore? I choose to make a 512MB file system and the arguments "-z -f creat=5 -f write=20 -f mkdir=5 -n 1000 -p 15" is to make sure that the dump operation would be against a full file system. I have read your patch "ext4/004: limit the amount of data written so test runs faster", it looks OK to me, sorry for the bothering. > > And I'll note that using the current fsstress arguments, you are only > creating regular files and directories, and there are no symlinks, > device nodes, or FIFO's being created to test whether those files are > correctly being backed up and restored. Yeah, I skipped these special files deliberately. Originally I used the arguments "-n 1000 -p 15". In RHEL7.0GA, restore tool will trigger a segmentation fault, the call trace is: --------------------------------------------------------------------- Program terminated with signal 11, Segmentation fault. #0 0x000000000040df24 in readxattr () ... (gdb) bt #0 0x000000000040df24 in readxattr () #1 0x000000000040e160 in extractattr () #2 0x000000000040e4e2 in extractfile () #3 0x00000000004097b0 in createleaves () #4 0x0000000000403ae6 in main () --------------------------------------------------------------------- The dump/restore version is 0.4b44, which is already latest. I have sent a bug report to Stelian Pop, maintainer of dump/restore. Later if this issue is fixed, I'll send patch to improve this 004 case, let it handle types of files, sorry. Regards, Xiaoguang Wang > > Cheers, > > - Ted > . >