The quick-read translator is used to cache a few KB of the contents of a file to speed up small file access and some other operations. The problem is that the data is cached during the lookup fop. There are some kinds of accesses that do a lot of lookups but the data is not really needed. For example a recursive ls, a find or an rsync. In these cases, the current implementation reads, by default, 64 KB of each file during the lookup. This means that a lot of bandwidth is wasted transferring unneeded data, the operation is slowed down, and data that will not be used is wasting memory. The current solution is useful to optimize some calls to the brick (for example the open and readv fops never reach the bricks if the user reads less that 64 KB of data). However this becames a disadvantage when the user does not want to read the file at all. It's even worse if the volume contains millions of files and the user only wants to enumerate them. Maybe it would be better to cache this data when the user manifests his intention to access the file, for example in the open fop. This could also allow us to release the used memory (including the dict_t structure) once the last fd of an inode is closed. We have to do an additional call to the brick but many other operations will benefit from this.
http://review.gluster.org/4403 http://review.gluster.org/4406 are for addressing the similar issue.
I saw the bug 846240 but I thought it wasn't related (I didn't examine the code changes though, sorry). It seems that these patches cover the problem I described and much more. Thank you very much
*** This bug has been marked as a duplicate of bug 846240 ***