Bug 903723 - [RFE] Make quick-read cache the file contents in the open fop instead of lookup
Summary: [RFE] Make quick-read cache the file contents in the open fop instead of lookup
Status: CLOSED DUPLICATE of bug 846240
Alias: None
Product: GlusterFS
Classification: Community
Component: quick-read (Show other bugs)
(Show other bugs)
Version: mainline
Hardware: Unspecified Unspecified
Target Milestone: ---
Assignee: Raghavendra G
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2013-01-24 16:39 UTC by Xavi Hernandez
Modified: 2014-07-11 15:33 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-07-11 15:33:03 UTC
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

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

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 ***

Note You need to log in before you can comment on or make changes to this bug.