ne_grained;" rather than "return
> ctime;", with the comment changed from "keep the existing value" to "use
> a fine-grained value"?
It is a problem, and Linus pointed that out yesterday, which is why I
sent this earlier today:
https://lore.kernel
On Tue, 2023-09-19 at 16:52 +0200, Bruno Haible wrote:
> Jeff Layton wrote:
> > I'm not sure what we can do for this test. The nap() function is making
> > an assumption that the timestamp granularity will be constant, and that
> > isn't necessarily the case now.
>
> This is only of secondary
Jeff Layton wrote:
> I'm not sure what we can do for this test. The nap() function is making
> an assumption that the timestamp granularity will be constant, and that
> isn't necessarily the case now.
This is only of secondary importance, because the scenario by Jan Kara
shows a much more
Hi all,
For those of you still reading cluster-devel, please be aware that gfs2
and dlm development have now moved to g...@lists.linux.dev
Please subscribe to the new list to avoid missing new developments, by
sending a message to:
gfs2+subscr...@lists.linux.dev
The new list is hosted
On Tue, 2023-09-19 at 13:04 +0200, Jan Kara wrote:
> 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
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.
> >
> > For
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.
>
> For ext4, we only need to enable the FS_MGTIME flag.
Hi
