From: Xiaoguang Wang <wangxg.fnst@cn.fujitsu.com> To: Theodore Ts'o <tytso@mit.edu> Cc: fstests@vger.kernel.org, linux-ext4@vger.kernel.org, Dave Chinner <david@fromorbit.com> Subject: Re: [PATCH] ext4/004: add dump/restore test Date: Wed, 17 Dec 2014 13:16:27 +0800 [thread overview] Message-ID: <549111AB.60108@cn.fujitsu.com> (raw) In-Reply-To: <20141216025827.GO17575@thunk.org> 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 > . >
WARNING: multiple messages have this Message-ID (diff)
From: Xiaoguang Wang <wangxg.fnst@cn.fujitsu.com> To: "Theodore Ts'o" <tytso@mit.edu> Cc: <fstests@vger.kernel.org>, <linux-ext4@vger.kernel.org>, Dave Chinner <david@fromorbit.com> Subject: Re: [PATCH] ext4/004: add dump/restore test Date: Wed, 17 Dec 2014 13:16:27 +0800 [thread overview] Message-ID: <549111AB.60108@cn.fujitsu.com> (raw) In-Reply-To: <20141216025827.GO17575@thunk.org> 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 > . >
next prev parent reply other threads:[~2014-12-17 5:19 UTC|newest] Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-11-25 10:21 [PATCH] ext4/004: add dump/restore test Xiaoguang Wang 2014-11-25 10:21 ` Xiaoguang Wang 2014-12-01 5:45 ` Dave Chinner 2014-12-03 2:44 ` Xiaoguang Wang 2014-12-03 2:44 ` Xiaoguang Wang 2014-12-03 6:40 ` [PATCH v2] " Xiaoguang Wang 2014-12-03 6:40 ` Xiaoguang Wang 2014-12-03 7:49 ` Eryu Guan 2014-12-03 9:47 ` Xiaoguang Wang 2014-12-03 9:47 ` Xiaoguang Wang 2014-12-04 7:29 ` Eryu Guan 2014-12-05 7:16 ` [PATCH v3] ext4: " Xiaoguang Wang 2014-12-05 7:16 ` Xiaoguang Wang 2014-12-06 21:40 ` [PATCH] ext4/004: " Theodore Ts'o 2014-12-06 23:44 ` Dave Chinner 2014-12-08 1:44 ` Xiaoguang Wang 2014-12-08 1:44 ` Xiaoguang Wang 2014-12-16 2:58 ` Theodore Ts'o 2014-12-16 3:59 ` Dave Chinner 2014-12-16 15:53 ` Theodore Ts'o 2014-12-16 19:36 ` Dave Chinner 2014-12-17 5:16 ` Xiaoguang Wang [this message] 2014-12-17 5:16 ` Xiaoguang Wang
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=549111AB.60108@cn.fujitsu.com \ --to=wangxg.fnst@cn.fujitsu.com \ --cc=david@fromorbit.com \ --cc=fstests@vger.kernel.org \ --cc=linux-ext4@vger.kernel.org \ --cc=tytso@mit.edu \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.