Re: [PATCH 3/7] FS-Cache: Avoid ENFILE checking for kernel-specific open files

[David Howells <dhowells@redhat.com>]

Andrew Morton <akpm@osdl.org> wrote:

> That would seem to be a great shortcoming in fscache.

It's not something that's easy to get around.  The file has to be "open" to be
able to do certain operations on it.

> I guess as memory reclaim reaps the top-level dentries those file*'s will
> also be freed up, leading to their dentries becoming reclaimable, leading
> to their inodes being reclaimable.

Exactly.

> But still.  Is it not possible to release those files-pinned-by-dcache when
> the top-level files are closed?

No, for three (or maybe four) reasons:

 (1) You assume there's a "top-level" file open.  AFS lookup(), for example,
     will read the cache to get the directory contents, but there will _not_
     be an open top-level file.

     We could open and close the cache file in each lookup(), but that could
     be very bad for lookup performance.

 (2) mmap() may still have the struct file open, even though the last close()
     has happened.

 (3) There may be pages not yet written to the cache outstanding.  These
     belong to the netfs *inode* not the netfs *file*.  Whilst the flush or
     release file operation could be made to wait for these, that's not
     necessarily within their spec, and could take a long time.  How far is
     the flush op supposed to go anyway?

 (4) It prevents the data file going away whilst we have a cookie for it
     (someone might go into the cache and delete something they shouldn't).

     Pinning the dentry might work just as well, I suppose, but it makes
     little difference to the resource consumption.

     We keep at least the dentry available so that we can honour the netfs's
     requests to update the auxiliary data as quickly as possible.

David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/