John Groves <John@xxxxxxxxxx> wrote: > I have modified the lustre client filesystem to use fscache, and it is in a > rudimentary working state. Excellent! > Among my most pressing requirements is to purge the fscache for any extent > for which a DLM lock is revoked. Hmmm... Do you have an open cookie on an FS-Cache object at the time this lock is revoked? Or are you looking for a shortcut - the equivalent of a delete op - by which you can supply a key and say 'delete that if it's there'? Note that I cannot provide you with functionality to punch holes in files in the cache very easily, not until the filesystems available to CacheFiles get that capability. > To the end of proving that functionality, I would like to give myself a file > ioctl that would determine what is in the fscache for a given file. Since > this is for testing, performance isn't a major concern. I'm already doing > this with the page cache, and I hope something similar would be possible > with the fscache. So, you want to be able to get, say, a bitmap of all the pages resident in the disk cache for a particular cookie - mass bmap() if you will? > Is there a supported way to query whether a given page_index is in the > fscache? If not, I'd appreciate suggestions as to how to go about this (or > insight into how other implementers have proven functionality without this > feature). I'm fairly ignorant as to the internals of fscache... Currently, the only way to do this is to try reading it, and observe the error code. It's not a requirement I've come across to date. What exactly is it that you want this functionality for? Just debugging (proving) that what you ask to be cached actually winds up in the cache? What you ask for shouldn't be too hard to provide - after all, I have to do the work anyway in order to determine whether I should return ENODATA or begin a read op in CacheFiles. If it's merely for debugging, then there's probably no particular need to optimise it to be fast. John Groves <John@xxxxxxxxxx> also wrote: > I'd like to add one more question... when I explicitly clean out the page > cache, so as to force reads to be satisfied from the fscache, I frequently > find that not all of my pages are available from the fscache. Hmmm... That doesn't sound good. What version of fscache and kernel are you using? Have you checked the statistics that are put in /proc/fs/fscache/stats to see if they give you some clue? > I don't know why this is, but I suspect that calling my releasepage method > (from an ioctl, after loading the cache & fscache) sometimes frees the > page(s) before fscache gets around to storing them...though that doesn't make > sense if fscache bumps the page reference count until it has made a copy or > written it out. fscache doesn't keep a ref on the pages directly, though the cache might (the cache that writes directly to blockdev certainly does by pasting them into BIOs). What fscache does is to use a couple of page bits on the page to mark its interest in a netfs page. One (PG_fscache) merely notes that fscache has an interest in that page and that fscache_uncache_page() should be called on it; the other (PG_fscache_write) indicates that a page is being written to the cache, and that the caller should wait on it till it gets cleared if they need the page. Can you show me your releasepage() method? > (does fscache consider my page dirty for the purpose of writing to > cachefiles, or does it make a copy, fscache doesn't make a copy of your page, but the cache might. In this case, CacheFiles does because I can't work out how to use the AIO interface from the kernel. As I mentioned above, fscache marks its interest in the page at this point by marking it with PG_fscache_write. This means the page may be written to the cache at some point. Of course, the cache is always at liberty to refuse due to things like ENOSPC, EIO and ENOMEM. If this happens, it _should_ show up in /proc/fs/fscache/stats. The main purpose of fscache is to insulate as best it can the netfs from errors in the cache and to hide at least some of the delays involved. > and is it susceptible to having a page freed out from under it? In such a case, firstly __free_pages() should bark, and secondly, you're likely to get gibberish in the cache, not just missing pages. > ...in which case is there a way to perform an explicit flush [preferably on > the whole file/object rather than one page at a time]? That's something I can look at. The problem with performing an explicit flush is that involves flushing stuff that's on the queues to be processed by other processes. Part of the problem is that stores are batched to save a certain amount of common time when it comes to actually doing the work. I really should move the batching further down, and, in CacheFiles's case, offer it to the underlying fs to do. The BTRFS person is in favour of that. David -- Linux-cachefs mailing list Linux-cachefs@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cachefs
