[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161103234802.GK14023@dastard>
Date: Fri, 4 Nov 2016 10:48:02 +1100
From: Dave Chinner <david@...morbit.com>
To: Theodore Ts'o <tytso@....edu>,
Deepa Dinamani <deepa.kernel@...il.com>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
arnd@...db.de, tglx@...utronix.de, gregkh@...uxfoundation.org,
akpm@...ux-foundation.org, viro@...iv.linux.org.uk,
y2038@...ts.linaro.org, linux-afs@...ts.infradead.org,
Andreas Dilger <adilger.kernel@...ger.ca>,
linux-ext4@...r.kernel.org
Subject: Re: [RFC 0/6] vfs: Add timestamp range check support
On Thu, Nov 03, 2016 at 04:43:57PM -0400, Theodore Ts'o wrote:
> On Thu, Nov 03, 2016 at 09:48:27AM +1100, Dave Chinner wrote:
> >
> > We're going to need regression tests for this to ensure that it
> > works properly and that we don't inadvertantly break it in future.
> > Can you write some xfstests that exercise this functionality and
> > validate that the mount behaviour, clamping and range limiting is
> > working as intended?
>
> In order to have automated regression tests which are file system
> independent, we need a way to query what are the timestamps that a
> particular mounted file systme supports.
We don't need that - we simply code it directly into the test
infrastructure, like we've done for things like the maximum number
of ACLs a filesystem supports (common/attr::_acl_get_max()).
> The last option, which is admittedly ugly, would be to create an shell
> function which knows how to figure out the max_timestamp and
> min_timestamp by using the file system name and querying the
> superblock using dumpe2fs, xfs_db, etc.
Yup, precisely that. We shouldn't trust the kernel to tell us the
correct thing to enable the test that tells us that thing is working
correctly or not...
> I'd argue for the last option because once we do get a programmtic way
> to get the information via a system call such as fsinfo(2), we can
> convert xfstests to use it, where as if we add an ioctl to return this
> information, we'll have to support the ioctl forever.
We have to support kernels that won't ever have something like
fsinfo, so it has to be done the "ugly way".
Cheers,
Dave.
--
Dave Chinner
david@...morbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists