David Howells wrote:
David Howells <dhowells redhat com> 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 redhat com https://www.redhat.com/mailman/listinfo/linux-cachefs
DavidI 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