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.
Regards--
Subrata
On Sat, Jul 5, 2008 at 11:05 PM, Theodore Ts'o <[email protected]> wrote:
> The following set of patches are being prepared for pushing to Linus
> during the next patch window. Aside from a large number of cleanups
> the big new feature in this patchset is delayed allocation support.
>
> I've been running this patch series on my laptop for the past couple
> of days in production, and it's been working quite well for me.
>
> - Ted
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Regards & Thanks--
Subrata
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