David Howells wrote:
David Howells <dhowells@xxxxxxxxxx> wrote:
I'm slightly perplexed that I have one retrieval that persists in failing to
retrieve anything. It is, however, something I've reduced to a read of a
single file, so I should be able to debug that.
Okay, it's not a bug... at least not in my code. The problem is that my test
isn't just a tar, it's a cat and a tar, and when doing the cat, nfs_readpage()
is asked to read one page beyond the end of the file (which is odd), and oddly
enough, FS-Cache never has any data for that extra page.
David
--
Linux-cachefs mailing list
Linux-cachefs@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cachefs
David
I was going to say I have found away to reproduce. I boot the
2.6.29-rc3 kernel and start my copy of the kernel source code tree, I do
this a few times to know cache is populated and working. I then boot
into the 2.6.30-rc2 kernel and start my copy again. Everything works as
expected until I run "find linux-2.6-nfs-fscache -exec touch {} \;" and
as expected all files are invalidated and the cache starts to repopulate
this continues on forever. I was going to suggest files getting created
in the cache wrong. If I then reboot back into 2.6.29-rc3, restart
copy, everything is copied over to populate the cache and after that it
works as expected. I think this is the same behavior other people are
seeing.
So I guess the question is now where does the bug lie? Also what
information would be helpful for me to provide to you. Looking at my
graphs every file is just invalidated by the cache since nothing ever
matches, I believe this is the behavior that you saw.
Thanks
Edward
--
Linux-cachefs mailing list
Linux-cachefs@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cachefs
