search for: fpathconf

...gt; static int > file_can_trim (void *handle) > { > - /* Trim is advisory, but we prefer to advertise it only when we can > - * actually (attempt to) punch holes. Since not all filesystems > - * support all fallocate modes, it would be nice if we had a way > - * from fpathconf() to definitively learn what will work on a given > - * fd for a more precise answer; oh well. */ The comment about fpathconf() would still be nice to keep in some form. > -#ifdef FALLOC_FL_PUNCH_HOLE > - return 1; > -#else > - return 0; > -#endif > + struct handle *h =...

...ile_can_trim (void *handle) > > { > > - /* Trim is advisory, but we prefer to advertise it only when we can > > - * actually (attempt to) punch holes. Since not all filesystems > > - * support all fallocate modes, it would be nice if we had a way > > - * from fpathconf() to definitively learn what will work on a given > > - * fd for a more precise answer; oh well. */ > > The comment about fpathconf() would still be nice to keep in some form. > But fpathconf does not tell anything abut this, no? > > > -#ifdef FALLOC_FL_PUNCH_HOLE >...

...ppability of the underlying file. */ static int file_can_trim (void *handle) { - /* Trim is advisory, but we prefer to advertise it only when we can - * actually (attempt to) punch holes. Since not all filesystems - * support all fallocate modes, it would be nice if we had a way - * from fpathconf() to definitively learn what will work on a given - * fd for a more precise answer; oh well. */ -#ifdef FALLOC_FL_PUNCH_HOLE - return 1; -#else - return 0; -#endif + struct handle *h = handle; + return h->can_punch_hole; } /* Read data from the file. */ @@ -252,34 +263,42 @@ file_pwri...

This is the second version to support efficient zero for block devices on older kernels (e.g. RHEL 7.5), and file systems that do not support yet FALLOC_FS_ZERO_RANGE (e.g. NFS 4.2). Changes since v1: - Split to smaller patches - Skip linux only includes on other systems - Skip code using BLKZEROOUT if the macro is not defined - Try BLKZEROOUT only if the offset and count are aligned to device

...+ + return statbuf.st_size; + } +} + +int +fileops_can_trim (void *handle) +{ + /* Trim is advisory, but we prefer to advertise it only when we can + * actually (attempt to) punch holes. Since not all filesystems + * support all fallocate modes, it would be nice if we had a way + * from fpathconf() to definitively learn what will work on a given + * fd for a more precise answer; oh well. */ +#ifdef FALLOC_FL_PUNCH_HOLE + return 1; +#else + return 0; +#endif +} + +int +fileops_can_fua (void *handle) +{ + return NBDKIT_FUA_NATIVE; +} + +int +fileops_can_cache (void *handle) +{ + /* Pre...

There's a lot of code in nbdkit-file-plugin which it would be nice to reuse elsewhere. One possible approach (as outlined here) is simply to move the file callbacks (like file.pread, file.pwrite, file.zero etc) to a new mini-library. They can then be consumed by other plugins fairly easily by doing: static void * foo_open (int readonly) { struct fileops *fops; int fd, flags; /*

I am the maintainer of GDM, and I am noticing that GDM has a problem when running on a ZFS filesystem, as with Indiana. When GDM (the GNOME Display Manager) starts the login GUI, it runs the following commands on Solaris: /usr/bin/setfacl -m user:gdm:rwx,mask:rwx /dev/audio /usr/bin/setfacl -m user:gdm:rwx,mask:rwx /dev/audioctl It does this because the login GUI programs are run as the

Needs some work still, see in particular the commit message for patch 3. Rich.

...000000000025 GLIBC_2.2.5 getsid 0000000000000000 DF *UND* 0000000000000428 Base init_pair 0000000000000000 DF *UND* 000000000000008d GLIBC_2.2.5 statvfs 0000000000000000 DF *UND* 0000000000000068 GLIBC_2.2.5 sinh 0000000000000000 DF *UND* 0000000000000215 GLIBC_2.2.5 fpathconf 0000000000000000 DF *UND* 000000000000001b GLIBC_2.2.5 dladdr 0000000000000000 DF *UND* 00000000000000bc Base _ZNSt3__120__get_collation_nameEPKc 0000000000000000 DF *UND* 00000000000000a9 Base __cxa_guard_acquire 0000000000000000 DF *UND* 0000000000000077 Base...

Hello, I update my building scripts to build LLVM 4.0 RC1 (with clang, lldb, libc++, libc++abi, lld) on CentOS 6 and I got a lot of undefined symbols during linking LLDB. I'm using clang-3.9 and this configuration: -DLLVM_TARGETS_TO_BUILD="X86" -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER=/usr/bin/clang -DCMAKE_CXX_COMPILER=/usr/bin/clang++