From: Greg Freemyer <greg.freemyer@gmail.com>
To: tytso@mit.edu
Cc: Akira Fujita <a-fujita@rs.jp.nec.com>,
ext4 development <linux-ext4@vger.kernel.org>,
OHSM-DEV <ohsm-devel@lists.sourceforge.net>
Subject: Re: [PATCH 1/3] ext4: Fix insertion point of extent in mext_insert_across_blocks()
Date: Thu, 4 Mar 2010 00:50:33 -0500 [thread overview]
Message-ID: <87f94c371003032150q64046db9h815d4cb630bb7a12@mail.gmail.com> (raw)
In-Reply-To: <20100304012508.GD3530@thunk.org>
>
> P.S. Here's another random idea for how we might aggressively test
> the EXT4_IOC_MOVE_EXT ioctl: (1) create an empty filesystem, (2)
> create a tool which randomly sets 50% of the bits in the block
> allocation bitmap, marking them as in use, and making the free space
> look very badly fragmented. (3) write a large number of files into
> the filesystem. (4) calculate the checksums for all of the files.
> (5) run e2fsck on the filesystem to fix up the block allocation
> bitmap. (6) defrag all of the files on the filesystem. (7) use
> e2fsck to make sure the filesystem is still consistent. (8) calculate
> the checksums for all of the files to make sure they still contain
> their original data.
Even that does not address issues with files in use during defrag.
ie. Defrag'ing a mysql database file while in use seems like an
important test case that is missing above.
Also, one issue with repetitive testing via the e4defrag tool, is you
only end up moving everything once and then in theory extra passes
have little to do.
The ohsm project has written a userspace "relocate" tool that calls
ext4_ioc_move_ext() to move files around on the filesystem.
In the absense of any ext4 ohsm kernel patches the blocks allocated to
the donor file would just use the normal block allocators. Therefore
it should be relatively easy to introduce an effect of just randomly
using ext4_ioc_move_ext() to change out the underlying blocks. It
maybe a useful in building up a test suite for ext4_ioc_move_ext().
In addition, for static files such as you describe above, we plan to
use the 60 GB or so of real world public domain data at
http://edrm.net/activities/projects/dataset as potential well known /
well defined real world data. That data already has published MD5
values available, so data corruption at any point in the process
should be readily identifiable.
Greg
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2010-03-04 5:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-03 6:49 [PATCH 1/3] ext4: Fix insertion point of extent in mext_insert_across_blocks() Akira Fujita
2010-03-04 1:25 ` tytso
2010-03-04 5:50 ` Greg Freemyer [this message]
2010-03-05 8:19 ` Akira Fujita
2010-03-05 16:10 ` tytso
2010-03-08 8:40 ` Akira Fujita
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=87f94c371003032150q64046db9h815d4cb630bb7a12@mail.gmail.com \
--to=greg.freemyer@gmail.com \
--cc=a-fujita@rs.jp.nec.com \
--cc=linux-ext4@vger.kernel.org \
--cc=ohsm-devel@lists.sourceforge.net \
--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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).