Re: [Cluster-devel] [PATCH v7 12/13] ext4: switch to multigrain timestamps
Jan Kara <[email protected]> Tue, 19 Sep 2023 13:04:57 +0200
| Newsgroups | com.redhat.cluster-devel,dev.linux.lists.ntfs3,dev.linux.lists.ocfs2-devel,dev.linux.lists.v9fs,net.sourceforge.lists.linux-f2fs-devel,org.infradead.lists.linux-mtd,org.kernel.vger.ceph-devel,org.kernel.vger.ecryptfs,org.kernel.vger.linux-btrfs,org.kernel.vger.linux-cifs,org.kernel.vger.linux-ext4,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-nfs,org.kernel.vger.linux-unionfs,org.kernel.vger.linux-xfs,org.kvack.linux-mm,org.ozlabs.lists.linux-erofs |
|---|---|
| Message-ID | <20230919110457.7fnmzo4nqsi43yqq@quack3> |
On Tue 19-09-23 15:05:24, Xi Ruoyao wrote: > On Mon, 2023-08-07 at 15:38 -0400, Jeff Layton wrote: > > Enable multigrain timestamps, which should ensure that there is an > > apparent change to the timestamp whenever it has been written after > > being actively observed via getattr. > >=20 > > For ext4, we only need to enable the FS_MGTIME flag. >=20 > Hi Jeff, >=20 > This patch causes a gnulib test failure: >=20 > $ ~/sources/lfs/grep-3.11/gnulib-tests/test-stat-time > test-stat-time.c:141: assertion 'statinfo[0].st_mtime < statinfo[2].st_mt= ime || (statinfo[0].st_mtime =3D=3D statinfo[2].st_mtime && (get_stat_mtime= _ns (&statinfo[0]) < get_stat_mtime_ns (&statinfo[2])))' failed > Aborted (core dumped) >=20 > The source code of the test: > https://git.savannah.gnu.org/cgit/gnulib.git/tree/tests/test-stat-time.c >=20 > Is this an expected change? Kind of yes. The test first tries to estimate filesystem timestamp granularity in nap() function - due to this patch, the detected granularity will likely be 1 ns so effectively all the test calls will happen immediately one after another. But we don't bother setting the timestamps with more than 1 jiffy (usually 4 ms) precision unless we think someone is watching. So as a result timestamps of all stamp1 and stamp2 files are going to be equal which makes the test fail. The ultimate problem is that a sequence like: write(f1) stat(f2) write(f2) stat(f2) write(f1) stat(f1) can result in f1 timestamp to be (slightly) lower than the final f2 timestamp because the second write to f1 didn't bother updating the timestamp. That can indeed be a bit confusing to programs if they compare timestamps between two files. Jeff? =09=09=09=09=09=09=09=09Honza > > Acked-by: Theodore Ts'o <[email protected]> > > Reviewed-by: Jan Kara <[email protected]> > > Signed-off-by: Jeff Layton <[email protected]> > > --- > > =A0fs/ext4/super.c | 2 +- > > =A01 file changed, 1 insertion(+), 1 deletion(-) > >=20 > > diff --git a/fs/ext4/super.c b/fs/ext4/super.c > > index b54c70e1a74e..cb1ff47af156 100644 > > --- a/fs/ext4/super.c > > +++ b/fs/ext4/super.c > > @@ -7279,7 +7279,7 @@ static struct file_system_type ext4_fs_type =3D { > > =A0=09.init_fs_context=09=3D ext4_init_fs_context, > > =A0=09.parameters=09=09=3D ext4_param_specs, > > =A0=09.kill_sb=09=09=3D kill_block_super, > > -=09.fs_flags=09=09=3D FS_REQUIRES_DEV | FS_ALLOW_IDMAP, > > +=09.fs_flags=09=09=3D FS_REQUIRES_DEV | FS_ALLOW_IDMAP | > > FS_MGTIME, > > =A0}; > > =A0MODULE_ALIAS_FS("ext4"); > > =A0 > >=20 >=20 --=20 Jan Kara <[email protected]> SUSE Labs, CR