* Re: Ext4 patches for the next merge window & Enhancements in 2.6.25
2008-07-05 19:02 Ext4 patches for the next merge window & Enhancements in 2.6.25 Subrata Modak
@ 2008-07-06 2:15 ` Theodore Tso
0 siblings, 0 replies; 2+ messages in thread
From: Theodore Tso @ 2008-07-06 2:15 UTC (permalink / raw)
To: Subrata Modak
Cc: Ext4 Developers List, ltp-list, Li Zefan, Shen Feng, Mingming Cao,
Julia Lawall, Andrew Morton, Jose R. Santos, Jan Kara,
Aneesh Kumar, Aneesh Kumar K.V, Alexey Dobriyan, Frederic Bohe,
Valerie Clement, Andreas Dilger, Alex Tomas, Dave Kleikamp,
Akinobu Mita, Eric Sandeen
On Sun, Jul 06, 2008 at 12:32:54AM +0530, Subrata Modak wrote:
> Hi Ted & Others,
>
> EXT4 has seen major enhancements in 2.6.25 and i can see few more
> enhancements for the next stable tree. I would like to know whether EXT4
> team has developed organized/automated test suites also to test EXT4
> features before releasing the patches to LKML. Apart from the normal
> fallocate() syscall test cases in LTP, we do not have any specific test case
> for the EXT4 file system. May i know if you have some thing to offer to LTP
> (http://ltp.sourceforge.net/) under GPL, or, any future plans to develop
> test cases as well.
We are using automated test runs via IBM's internal ABAT system; the
main thing we are doing is using various LTP and other filesystem
benchmarks as stress tests, so we don't have any _new_ tests suites
per se. The main thing which we have automated is the setup so that
the various test suites are run in a variety of different ext4 mount
modes and with different ext4 features enabled/disabled.
My understanding is that this goes beyond the scope of what the LTP
supports, since it tends to be very specific to the configuration of
the System Under Test.
This is an area where I suspect if the LTP wanted to expand into, it
would be very useful; however, I would suggest doing it in a
filesystem independent manner. Essentially at an abstract level, you
want to be able to iterate over a series of filesystem types (i.e.,
xfs, ext4, ext3, btrfs, etc.), and for each filesystem type, it would
supply a set of mkfs/mount options, and a script for creating and
mounting a filesystem with that set of mkfs and mount options, and
then LTP would run a series of generic filesystem tests and
benchmarks, and then the filesystem would be unmounted, and the next
set of mkfs/mount options would be used, etc.
Essentially ext4 is a generic POSIX-compliant filesystem. It has some
extentions for acl's, extended attributes, etc. --- but these
extensions use the same interfaces as those found in ext3 and xfs (and
presumably btrfs as well). Given that the bulk of the POSIX
compliance is done in the VFS, it is highly likely that most of the
components of a functional test of the POSIX interfaces (i.e., such as
you might find in the LSB test suite) will pass; a few are implemented
in a filesystem layer, so it's good to run those tests --- but that's
not the big deal. The big deal is doing a stress test of the
filesystem to test for potential deadlocks, etc., when the system is
under serious load. So the sort of testing which will be useful for
ext4 (or any filesystem, really) is what happens when kernbench is run
in the background at the same time as bonnie, or postmark, or other fs
benchmarks.
Something else that would be great to automate is simulating I/O
errors, but unfortunately this would require root privileges and
probably kernel patches (I don't think error injection via device
mapper is in mainline, for example). This is something we haven't
done yet, but it is something that we definitely need to do, in order
to make sure the filesystem handles media errors in a graceful
fashion.
So the bottom line is that we don't have any *code* in terms of actual
test suites to contribute to the LTP. It would be great if the LTP
was interested in solving the much more generic filesystem test
framework problem, but it may be that this is out of scope of the LTP
and it is something which should be done as a separate project.
Regards,
- Ted
^ permalink raw reply [flat|nested] 2+ messages in thread