On Wed, Apr 24, 2019 at 05:02:42PM +0200, Miklos Szeredi wrote:
On Wed, Apr 24, 2019 at 4:22 PM Kirill Smelkov kirr@nexedi.com wrote:
FUSE_PRECISE_INVAL_DATA:
--- b/include/uapi/linux/fuse.h +++ b/include/uapi/linux/fuse.h @@ -266,7 +266,7 @@ * FUSE_MAX_PAGES: init_out.max_pages contains the max number of req pages * FUSE_CACHE_SYMLINKS: cache READLINK responses * FUSE_NO_OPENDIR_SUPPORT: kernel supports zero-message opendir
- FUSE_PRECISE_INVAL_DATA: filesystem is fully responsible for data cache invalidation
*/
- FUSE_PRECISE_INVAL_DATA: filesystem is fully responsible for invalidation
#define FUSE_ASYNC_READ (1 << 0) #define FUSE_POSIX_LOCKS (1 << 1)
the "data cache" in "for data cache invalidation" has particular meaning and semantic: the filesystem promises to explicitly invalidate data of
Right; better name: FUSE_EXPLICIT_INVAL_DATA. Will push fixed version.
- * FUSE_PRECISE_INVAL_DATA: filesystem is fully responsible for invalidation + * FUSE_EXPLICIT_INVAL_DATA: only invalidate cached pages on explicit request
...
/** Filesystem is fully reponsible for page cache invalidation. */ - unsigned precise_inval_data:1; + unsigned explicit_inval_data:1;
Ok, let it be this way.
Your amendment for FOPEN_STREAM in uapi/linux/fuse.h (see above) also suggests that it is better to be more explicit in that file.
--- b/fs/fuse/inode.c +++ b/fs/fuse/inode.c @@ -913,13 +913,8 @@ fc->dont_mask = 1; if (arg->flags & FUSE_AUTO_INVAL_DATA) fc->auto_inval_data = 1; - if (arg->flags & FUSE_PRECISE_INVAL_DATA) + else if (arg->flags & FUSE_PRECISE_INVAL_DATA) fc->precise_inval_data = 1; - if (fc->auto_inval_data && fc->precise_inval_data) { - pr_warn("filesystem requested both auto and " - "precise cache control - using auto\n"); - fc->precise_inval_data = 0; - } if (arg->flags & FUSE_DO_READDIRPLUS) { fc->do_readdirplus = 1; if (arg->flags & FUSE_READDIRPLUS_AUTO)Even though it is ok for me personally (I could be careful and use only FUSE_PRECISE_INVAL_DATA) I still think usage of both "auto" and "precise" invalidation modes deserves a warning. It is only at filesystem init time. What is the reason not to print it?
The warning makes no sense. It should either be failure or silent override.
Ok.
"fuse: retrieve: cap requested size to negotiated max_write"
Signed-off-by: Kirill Smelkov kirr@nexedi.com Cc: Han-Wen Nienhuys hanwen@google.com Cc: Jakob Unterwurzacher jakobunt@gmail.com -Cc: stable@vger.kernel.org # v2.6.36+
what is the reason not to include this patch into stable series?
This doens't fix any bugs out there, but there is a slight chance of regression (so it might possibly have to be reverted in the future) so it absolutely makes no sense to backport it to stable.
Ok.
Thanks again for tossing the patches,
Kirill