linux-ext4 - Re: [PATCH] ext4/004: add dump/restore test

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 15 Dec 2014 21:58:27 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	Xiaoguang Wang <wangxg.fnst@...fujitsu.com>
Cc:	fstests@...r.kernel.org, linux-ext4@...r.kernel.org
Subject: Re: [PATCH] ext4/004: add dump/restore test

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
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html