Re: lookup caching

[Raghavendra G <raghavendra@xxxxxxxxxxx>]

On Mon, Apr 12, 2010 at 1:26 PM, Olivier Le Cam <Olivier.LeCam@xxxxxxxxxxxxxxxxxxxxx> wrote:

Hello there,

Raghavendra G wrote:

   I can see three protocol calls:
          - client_open()         (to both servers)            - client_stat()         (to one server only: load balancing?)
          - client_flush()        (to both servers)


io-cache indeed sends open and flush to server. This is needed for correct working of io-cache. As you've told below, since you are overriding lookup call, stat is sent to server (stat and lookup are two different calls).

OK. So no easy workaround can get rid of that. Right?

you've to override stat also.
 

since lookup is being unwound if the stat is cached for an inode, you've to also implement calls like unlink, rmdir (which deletes files/directories) and flush the cache corresponding to the inode. Otherwise lookup will be succeeding even for unlinked files, but the actual operations (like open/chmod/chown etc) will fail.

I have added this yesterday afternoon, as well as some LOCK/UNLOCK in order to prevent concurrency problems. :)

You should also handle calls which can change the stat of a file or directory (like write/chmod/chown). As a simple implementation you can just flush the cache.

I did override setattr and fsetattr (for flushing the cache). Is it wrong? Do I have to override write/chmod/chown either?

You are right., chmod and chown are replaced by setattr. Sorry  about that:). You need to flush the cache during write also. In general any fop that can potentially change stat should be implemented.

          if (cache->next) {
                  do {
                          cache = cache->next;
                          if (cache->ino == ino) {


instead of just returning, you can choose to update the cached stat with the one passed as argument to this procedure.
 
                                  return 0;       /* already in */
                          }
                  } while(cache->next);
          }

Thanks for suggestion.

Best regards,
--
Olivier

_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxx
http://lists.nongnu.org/mailman/listinfo/gluster-devel

-- 
Raghavendra G