From: Jan Kara <jack@suse.cz>
To: "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: Petr Vorel <pvorel@suse.cz>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Jan Kara <jack@suse.cz>,
linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
Cyril Hrubis <chrubis@suse.cz>, Yong Sun <yosun@suse.com>
Subject: Re: "New" ext4 features tests in LTP
Date: Thu, 24 Oct 2019 09:46:19 +0200 [thread overview]
Message-ID: <20191024074619.GI31271@quack2.suse.cz> (raw)
In-Reply-To: <20191023225824.GB7630@mit.edu>
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 <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2019-10-24 7:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-23 15:58 "New" ext4 features tests in LTP Petr Vorel
2019-10-23 22:58 ` Theodore Y. Ts'o
2019-10-24 7:46 ` Jan Kara [this message]
2019-10-24 8:37 ` Petr Vorel
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=20191024074619.GI31271@quack2.suse.cz \
--to=jack@suse.cz \
--cc=adilger.kernel@dilger.ca \
--cc=chrubis@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=pvorel@suse.cz \
--cc=tytso@mit.edu \
--cc=yosun@suse.com \
/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