search for: posix_fadv_

The way we used posix_fadvise was wrong, and yet right! Rich.

On Fri, Aug 11, 2017 at 05:50:47PM +0530, Ravishankar N wrote: > > > On 08/11/2017 04:51 PM, Niels de Vos wrote: > > On Fri, Aug 11, 2017 at 12:47:47AM -0400, Raghavendra Gowdappa wrote: > > > Hi all, > > > > > > In a conversation between me, Milind and Csaba, Milind pointed out > > > fadvise(2) [1] and its potential benefits to Glusterfs'

...100644 --- a/plugins/file/file.c +++ b/plugins/file/file.c @@ -64,8 +64,8 @@ #define fdatasync fsync #endif -static char *filename = NULL; -static char *directory = NULL; +static const char *filename = NULL; +static const char *directory = NULL; /* posix_fadvise mode: -1 = don't set it, or POSIX_FADV_*. */ static int fadvise_mode = @@ -91,13 +91,6 @@ is_enotsup (int err) return err == ENOTSUP || err == EOPNOTSUPP; } -static void -file_unload (void) -{ - free (filename); - free (directory); -} - /* Called for each key=value passed on the command line. This plugin * only accepts file=&...

...inter to the file_operations. It is not impossible > to convince the Linux VFS developers, but it would not be as trivial as > adding it to FUSE only (but that requires the VFS infrastructure to be > there). Well, question is: are strategies of the caching xlators' mapping well to the POSIX_FADV_* hint set? Would an application that might run on a GlusterFS storage backend use fadvise(2) anyway or would fadvise calls be added particularly to optimize the GlusterFS backed scenario? Because if usage of fadvise were specifically to address the GlusterFS backend -- either because of specifc se...

...It is not impossible > > to convince the Linux VFS developers, but it would not be as trivial as > > adding it to FUSE only (but that requires the VFS infrastructure to be > > there). > > Well, question is: are strategies of the caching xlators' mapping well to > the POSIX_FADV_* hint set? Would an application that might run on > a GlusterFS storage backend use fadvise(2) anyway or would fadvise calls > be added particularly to optimize the GlusterFS backed scenario? > +Pranith, +ravi. If I am not wrong, afr too has strategies like eager-locking if writes are se...

Add wrappers around posix_fadvise and use them in places we were calling posix_fadvise directly before. Also in virt-builder we were doing this (and ignoring the result): posix_fadvise (fd, 0, 0, POSIX_FADV_RANDOM|POSIX_FADV_DONTNEED); However the POSIX_FADV_* flags are _not_ bitmasks! In fact POSIX_FADV_RANDOM|POSIX_FADV_DONTNEED == POSIX_FADV_NOREUSE so we were giving a completely different hint from what we thought we were giving. --- builder/pxzcat-c.c | 5 +-- src/guestfs-internal...

...to expose a file that resides on a file system known to diff --git a/plugins/file/file.c b/plugins/file/file.c index 076e7531..a8e37cd9 100644 --- a/plugins/file/file.c +++ b/plugins/file/file.c @@ -66,6 +66,18 @@ static char *filename = NULL; +/* posix_fadvise mode: -1 = don't set it, or POSIX_FADV_*. */ +static int fadvise_mode = +#if defined (HAVE_POSIX_FADVISE) && defined (POSIX_FADV_NORMAL) + POSIX_FADV_NORMAL +#else + -1 +#endif + ; + +/* cache mode */ +static enum { cache_default, cache_none } cache_mode = cache_default; + /* Any callbacks using lseek must be protected by thi...

More patches on the way for improving .list_exports signature and adding .export_description, but this is the promised code showing why nbdkit_string_intern is useful. Patch 4 is somewhat RFC: we could either add new API to take the boilerplate from: foo_config(const char *key, const char *value) { if (strcmp (key, "file") == 0) { CLEANUP_FREE char *tmp = nbdkit_realpath (value);