Bug 903723

Summary: [RFE] Make quick-read cache the file contents in the open fop instead of lookup
Product: [Community] GlusterFS Reporter: Xavi Hernandez <jahernan>
Component: quick-readAssignee: Raghavendra G <rgowdapp>
Status: CLOSED DUPLICATE QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: mainlineCC: gluster-bugs, ndevos, rwheeler, sasundar
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-07-11 15:33:03 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Xavi Hernandez 2013-01-24 16:39:58 UTC
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.

Comment 1 Amar Tumballi 2013-01-25 07:04:55 UTC
http://review.gluster.org/4403 
http://review.gluster.org/4406

are for addressing the similar issue.

Comment 2 Xavi Hernandez 2013-01-25 08:14:41 UTC
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

Comment 3 Niels de Vos 2014-07-11 15:33:03 UTC

*** This bug has been marked as a duplicate of bug 846240 ***