archive mirror
 help / color / mirror / Atom feed
From: David Howells <>
To: Max Kellermann <>
Subject: Re: fscache corruption in Linux 5.17?
Date: Tue, 19 Apr 2022 17:42:49 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Max Kellermann <> wrote:

> Did you read this part of my email?:

Sorry, I'm trying to deal with several things at once.

> My theory was that fscache shows a mix of old and new pages after the
> file was modified.  Does this make sense?

Okay - that makes a bit more sense.

Could the file have been modified by a third party?  If you're using NFS3
there's a problem if two clients can modify a file at the same time.  The
second write can mask the first write and the client has no way to detect it.
The problem is inherent to the protocol design.  The NFS2 and NFS3 protocols
don't support anything better than {ctime,mtime,filesize} - the change
attribute only becomes available with NFS4.

If an NFS file is opened for writing locally, the cache for it supposed to be
invalidated and remain unused until there are no open file descriptors left
referring to it.  This is intended for handling DIO writes, but it should
serve for this also.

The following might be of use in checking if the invalidation happens locally:

echo 1 >/sys/kernel/debug/tracing/events/fscache/fscache_invalidate/enable

And then this can be used to check if it correctly identifies that it has an
obsolete version of the file in the cache when it binds to it:

echo 1 >/sys/kernel/debug/tracing/events/cachefiles/cachefiles_coherency/enable


  parent reply	other threads:[~2022-04-19 16:49 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-12 15:10 fscache corruption in Linux 5.17? Max Kellermann
2022-04-16 11:38 ` Thorsten Leemhuis
2022-04-16 19:55   ` Max Kellermann
2022-04-19 13:02 ` David Howells
2022-04-19 14:18   ` Max Kellermann
2022-04-19 15:23     ` [Linux-cachefs] " David Wysochanski
2022-04-19 16:17   ` David Howells
2022-04-19 16:41     ` Max Kellermann
2022-04-19 16:47     ` David Howells
2022-04-19 15:56 ` David Howells
2022-04-19 16:06   ` Max Kellermann
2022-04-19 16:42   ` David Howells [this message]
2022-04-19 18:01     ` Max Kellermann
2022-04-19 21:27     ` Max Kellermann
2022-04-20 13:55     ` David Howells
2022-05-04  8:38       ` Max Kellermann
2022-05-31  8:35       ` David Howells
2022-05-31  8:41         ` Max Kellermann
2022-05-31  9:13         ` David Howells
2022-06-20  7:11           ` Thorsten Leemhuis

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).