[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191024074619.GI31271@quack2.suse.cz>
Date: Thu, 24 Oct 2019 09:46:19 +0200
From: Jan Kara <jack@...e.cz>
To: "Theodore Y. Ts'o" <tytso@....edu>
Cc: Petr Vorel <pvorel@...e.cz>,
Andreas Dilger <adilger.kernel@...ger.ca>,
Jan Kara <jack@...e.cz>, linux-ext4@...r.kernel.org,
linux-fsdevel@...r.kernel.org, Cyril Hrubis <chrubis@...e.cz>,
Yong Sun <yosun@...e.com>
Subject: Re: "New" ext4 features tests in LTP
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@...e.com>
SUSE Labs, CR
Powered by blists - more mailing lists