From: Christian Brauner <brauner@kernel.org>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Jeff Layton <jlayton@kernel.org>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
Jan Kara <jack@suse.cz>, "Darrick J. Wong" <djwong@kernel.org>
Subject: Re: [GIT PULL v2] timestamp fixes
Date: Sun, 24 Sep 2023 12:26:51 +0200 [thread overview]
Message-ID: <20230924-trial-dennoch-e641f0e0ee1b@brauner> (raw)
In-Reply-To: <CAOQ4uxgFb250Na9cJz0Jo-ioPynWCk0vxTDU-6hAKoEVQhgvRg@mail.gmail.com>
> > Those workloads are broken garbage, and we should *not* use that kind
> > of sh*t to decide on VFS internals.
> >
>
> Sorry, I phrased it completely wrong.
Thanks for clearing this up. I had just formulated my own reply but I'll
happily delete it. :)
> The workloads don't expect 1ns resolution.
Yes, they don't. In the revert explanation I just used that number to
illustrate the general ordering problem. The workload that surfaced the
issue is just plain weird of course but it points to a more general
ordering problem.
> The workloads just compare timestamps of objects and expect some sane
> not-before ordering rules.
Yes.
> If user visible timestamps are truncated to 100ns all is good.
Yes.
next prev parent reply other threads:[~2023-09-24 10:26 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-21 11:20 [GIT PULL v2] timestamp fixes Christian Brauner
2023-09-21 18:24 ` Linus Torvalds
2023-09-21 18:51 ` Jeff Layton
2023-09-21 19:28 ` Linus Torvalds
2023-09-21 19:46 ` Linus Torvalds
2023-09-21 21:57 ` Jeff Layton
2023-09-22 12:28 ` Christian Brauner
2023-09-22 10:19 ` David Sterba
2023-09-23 6:36 ` Amir Goldstein
2023-09-23 17:48 ` Linus Torvalds
2023-09-23 19:30 ` Theodore Ts'o
2023-09-23 20:03 ` Linus Torvalds
2023-09-23 22:07 ` Theodore Ts'o
2023-09-23 23:31 ` Linus Torvalds
2023-09-23 21:29 ` Amir Goldstein
2023-09-24 10:26 ` Christian Brauner [this message]
2023-09-25 11:22 ` Jeff Layton
2023-09-25 16:02 ` Linus Torvalds
2023-09-22 12:24 ` Christian Brauner
2023-09-24 8:34 ` Amir Goldstein
2023-09-24 10:15 ` Christian Brauner
2023-09-22 12:16 ` Christian Brauner
2023-09-21 20:10 ` pr-tracker-bot
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=20230924-trial-dennoch-e641f0e0ee1b@brauner \
--to=brauner@kernel.org \
--cc=amir73il@gmail.com \
--cc=djwong@kernel.org \
--cc=jack@suse.cz \
--cc=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.