-
Notifications
You must be signed in to change notification settings - Fork 49
Phone Conference, November 3rd 2011
The 'test' branch is now deleted. As said at BAT and during the last phone conference, 'next' is to be used instead.
Philippe opened issue#16 (lock test#2 fails) and issue#17 (Issue when running basic/test5). He solved and closed issue#17.
Regarding issue#16, Frank said that lock's debug messages would help a lot. To trigger these log messages on use this: export COMPONENT_NFS_V4_LOCK=NIV_FULL_DEBUG export COMPONENT_STATE=NIV_FULL_DEBUG
Philippe will send prototype and header for a new function designed to invalidate entries in the cache. The call will be atomic. Entries will be addressed by its fsal_handle_t to preserve atomicity of the function. If no entry with the related fsal_handle_t exists, then ENOENT is returned.
Discussion was made regarding invalidation vs update of the cache. Implementing the invalidation is easier and will be done first. Managing update of the cache (as a separate "protocol") will be done in a second time, but will be more complex. Boaz highlighted the fact that when "storm of updates" occurs, the invalidation will be more efficient (the first call will invalidate the entry, the later will get ENOENT). Marc insisted on the fact that update would be great to have as well. There are cases each of those policies (invalidation vs update) have advantages.
Philippe asked for details on the 'fanotify' API. Boaz indicated that fanotify could be used in a "recursive" way. Opening a fd on the exported root and fanotify on it would be enough to build FSAL_VFS upcalls. Boaz noticed that filtering is critcal : ganesha should not receive upcalls for changes on the backend it itself did. PID-based filters should prevent this.
Matt is working on TI-RPC based NFSv4 backchannels. They would be used for the NFSv4 Call Backs functions.
IBM (Jeremy and JV if I remember well) noticed that an export entry can be created and modify. This may cause taken FSAL resources (open fd, locks) not to be released properly. They suggest do have a mechanism to pause and resume the FSAL, with a queue to deal which the request made as the FSAL restart.
Boaz did not agree with this approach. He thinks that restarting the service is safer (but it will cause the loss of every previously cached stuff)
Philippe noticed that reconfiguring an export entry is a rare event : it almost never occur if compared to other things happening during the daemon's lifetime. Is it really worth implementing complex stuff for this. Philippe believes that the server should not be too nice with the client and prefers the client to have recovery process to deal with a dead/resurrected service.
- continue the topic about Pause/resume FSAL
- pNFS code from LinuxBox
- tests to be used to defined a common test platform.