From: Theodore Ts'o <tytso@mit.edu>
Subject: Re: [PATCH] ext4/004: add dump/restore test
Date: Mon, 15 Dec 2014 21:58:27 -0500
Message-ID: <20141216025827.GO17575@thunk.org>
References: <1416910869-28538-1-git-send-email-wangxg.fnst@cn.fujitsu.com>
 <20141206214040.GA27484@thunk.org>
 <54850290.2070201@cn.fujitsu.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: fstests@vger.kernel.org, linux-ext4@vger.kernel.org
To: Xiaoguang Wang <wangxg.fnst@cn.fujitsu.com>
Content-Disposition: inline
In-Reply-To: <54850290.2070201@cn.fujitsu.com>
Sender: linux-ext4-owner@vger.kernel.org

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?

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.

Cheers,

						- Ted