Hi,
we have in LTP some ext4 fs tests [1], which aimed to test at the time new ext4
features [2]. All of them are using The Flexible Filesystem Benchmark (ffsb)
- a filesystem performance measurement too [3]. Tests were contributed in 2009
and needs at least some cleanup.
I wonder whether testing these features is still relevant. And if yes, whether
they're covered in xfstests? After brief search in xfstests ext4 tests it
doesn't look like, at least not directly. Does it make sense to you to keep them?
(either to cleanup and keep them in LTP or rewrite and contribute to xfstests)
List of these tests [3]:
ext4-inode-version [4]
------------------
Directory containing the shell script which is used to test inode version field
on disk of ext4.
ext4-journal-checksum [5]
---------------------
Directory containing the shell script which is used to test journal checksumming
of ext4.
ext4-nsec-timestamps [6]
--------------------
Directory containing the shell script which is used to test nanosec timestamps
of ext4.
ext4-online-defrag [7]
------------------
Directory containing the shell script which is used to test online defrag
feature of ext4.
ext4-persist-prealloc [8]
---------------------
Directory containing the shell script which is used to test persist prealloc
feature of ext4.
ext4-subdir-limit [9]
-----------------
Directory containing the shell script which is used to test subdirectory limit
of ext4. According to the kernel documentation, we create more than 32000
subdirectorys on the ext4 filesystem.
ext4-uninit-groups [10]
------------------
Directory containing the shell script which is used to test uninitialized groups
feature of ext4.
Thanks for info.
Kind regards,
Petr
[1] https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/fs/ext4-new-features/README
[2] http://ext4.wiki.kernel.org/index.php/New_ext4_features
[3] https://github.com/linux-test-project/ltp/blob/master/utils/ffsb-6.0-rc2/README
[4] https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/fs/ext4-new-features/ext4-inode-version/ext4_inode_version_test.sh
[5] https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/fs/ext4-new-features/ext4-journal-checksum/ext4_journal_checksum.sh
[6] https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/fs/ext4-new-features/ext4-nsec-timestamps/ext4_nsec_timestamps_test.sh
[7] https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/fs/ext4-new-features/ext4-online-defrag/ext4_online_defrag_test.sh
[8] https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/fs/ext4-new-features/ext4-persist-prealloc/ext4_persist_prealloc_test.sh
[9] https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/fs/ext4-new-features/ext4-subdir-limit/ext4_subdir_limit_test.sh
[10] https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/fs/ext4-new-features/ext4-uninit-groups/ext4_uninit_groups_test.sh
On Wed, Oct 23, 2019 at 05:58:46PM +0200, Petr Vorel wrote:
> ext4-inode-version [4]
> ------------------
> Directory containing the shell script which is used to test inode version field
> on disk of ext4.
This is basically testing whether or not i_version gets incremented
after various file system operations. There's some checks about
whether i_version is 32 bit or 64 bit based on the inode size, which
seems a bit pointless, and also checking whether the file system can
be mounted as ext3, which is even more pointless.
The i_version increment check can be done in a much more general (file
systme independant) way by using the FS_IOC_GETVERSION ioctl (there is
also an FS_IOC_SETVERSION).
> ext4-journal-checksum [5]
> ---------------------
> Directory containing the shell script which is used to test journal checksumming
> of ext4.
This is basically checking whether you can mount an ext4 file system
with the journal checksum options. Seems kinda pointless to me. I'm
guessing that perhaps the test authors were trying to hit some
artificial code coverage metric, perhaps?
> ext4-nsec-timestamps [6]
> --------------------
> Directory containing the shell script which is used to test nanosec timestamps
> of ext4.
This basically tests that the file system supports nanosecond
timestamps, with a 0.3% false positive failure rate. Again, why?
> ext4-online-defrag [7]
> ------------------
> Directory containing the shell script which is used to test online defrag
> feature of ext4.
We already have tests of online defrag in xfstests: ext4/301,
ext4/302, ext4/303, and ext4/304. And they do a much better job of
stress testing the defrag code than the very simple "let's tickle the
code paths to hit the code coverage metric" style of testing in this
script.
> ext4-persist-prealloc [8]
> ---------------------
> Directory containing the shell script which is used to test persist prealloc
> feature of ext4.
We have lots and lots of fallocate tests in xfstests. what is in ltp
is just "let's run fallocate in the happy path, without any stress
tests" style test. There's a reason why a lot of people really like
to hate on pointed-haired managers who push for code coverage
metrics....
> ext4-subdir-limit [9]
> -----------------
> Directory containing the shell script which is used to test subdirectory limit
> of ext4. According to the kernel documentation, we create more than 32000
> subdirectorys on the ext4 filesystem.
This is a valid test, although it's not what I would call a "high
value" test. (As in, it's testing maybe a total of four simple lines
of code that are highly unlikely to fail.)
> ext4-uninit-groups [10]
> ------------------
> Directory containing the shell script which is used to test uninitialized groups
> feature of ext4.
The uninitialized block group feature is enabled by default for ext4
these days, and we do extensive testing with it enabled. I also test
in ext3 compatibility mode, which tests the "not unitialized groups
case". The oldalloc mount option is a no-op these days, so the fact
that the ltp test tries to test orlov versus oldalloc is pointless.
Cheers,
- Ted
On Wed 23-10-19 18:58:24, Theodore Y. Ts'o wrote:
> On Wed, Oct 23, 2019 at 05:58:46PM +0200, Petr Vorel wrote:
> > ext4-inode-version [4]
> > ------------------
> > Directory containing the shell script which is used to test inode version field
> > on disk of ext4.
>
> This is basically testing whether or not i_version gets incremented
> after various file system operations. There's some checks about
> whether i_version is 32 bit or 64 bit based on the inode size, which
> seems a bit pointless, and also checking whether the file system can
> be mounted as ext3, which is even more pointless.
>
> The i_version increment check can be done in a much more general (file
> systme independant) way by using the FS_IOC_GETVERSION ioctl (there is
> also an FS_IOC_SETVERSION).
Yeah, I believe this may be useful to implement in fstests in some fs
agnostic way.
> > ext4-nsec-timestamps [6]
> > --------------------
> > Directory containing the shell script which is used to test nanosec timestamps
> > of ext4.
>
> This basically tests that the file system supports nanosecond
> timestamps, with a 0.3% false positive failure rate. Again, why?
>
> > ext4-subdir-limit [9]
> > -----------------
> > Directory containing the shell script which is used to test subdirectory limit
> > of ext4. According to the kernel documentation, we create more than 32000
> > subdirectorys on the ext4 filesystem.
>
> This is a valid test, although it's not what I would call a "high
> value" test. (As in, it's testing maybe a total of four simple lines
> of code that are highly unlikely to fail.)
These two may be IMHO worth carrying over to fstests in some form. The other
tests seem either already present in various fstests configs we run or
pointless as Ted wrote.
Honza
--
Jan Kara <[email protected]>
SUSE Labs, CR
Hi Ted, Jan,
> Yeah, I believe this may be useful to implement in fstests in some fs
> agnostic way.
Thank you both for reviewing LTP tests.
> > > ext4-nsec-timestamps [6]
> > > --------------------
> > > Directory containing the shell script which is used to test nanosec timestamps
> > > of ext4.
> > This basically tests that the file system supports nanosecond
> > timestamps, with a 0.3% false positive failure rate. Again, why?
> > > ext4-subdir-limit [9]
> > > -----------------
> > > Directory containing the shell script which is used to test subdirectory limit
> > > of ext4. According to the kernel documentation, we create more than 32000
> > > subdirectorys on the ext4 filesystem.
> > This is a valid test, although it's not what I would call a "high
> > value" test. (As in, it's testing maybe a total of four simple lines
> > of code that are highly unlikely to fail.)
> These two may be IMHO worth carrying over to fstests in some form. The other
> tests seem either already present in various fstests configs we run or
> pointless as Ted wrote.
As Sero already volunteered to contribute them to fstests (thanks Sero!),
I'll send a patch to delete them from LTP.
> Honza
Kind regards,
Petr