[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6688504.ZJKUV3z3ry@silver>
Date: Wed, 04 May 2022 20:33:36 +0200
From: Christian Schoenebeck <linux_oss@...debyte.com>
To: asmadeus@...ewreck.org
Cc: David Howells <dhowells@...hat.com>,
David Kahurani <k.kahurani@...il.com>, davem@...emloft.net,
ericvh@...il.com, kuba@...nel.org, linux-kernel@...r.kernel.org,
lucho@...kov.net, netdev@...r.kernel.org,
v9fs-developer@...ts.sourceforge.net, Greg Kurz <groug@...d.org>
Subject: Re: 9p EBADF with cache enabled (Was: 9p fs-cache tests/benchmark (was: 9p
fscache Duplicate cookie detected))
On Dienstag, 3. Mai 2022 12:21:23 CEST asmadeus@...ewreck.org wrote:
[...]
> - add some complex code to track the exact byte range that got updated
> in some conditions e.g. WRONLY or read fails?
> That'd still be useful depending on how the backend tracks file mode,
> qemu as user with security_model=mapped-file keeps files 600 but with
> passthrough or none qemu wouldn't be able to read the file regardless of
> what we do on client...
> Christian, if you still have an old kernel around did that use to work?
Sorry, what was the question, i.e. what should I test / look for precisely? :)
[...]
> > > Also, can you get the contents of /proc/fs/fscache/stats from after
> > > reproducing the problem?
> >
> > FS-Cache statistics
>
> (He probably wanted to confirm the new trace he added got hit with the
> workaround pattern, I didn't get that far as I couldn't compile my
> reproducer on that fs...)
Yeah, I got that. But since his patch did not apply, I just dumped what I got
so far in case the existing stats might be useful anyway.
Best regards,
Christian Schoenebeck
Powered by blists - more mailing lists