search for: sync_file_rang

.../vg01/lv_osd_journal_0 fd 15: 17179869184 bytes, block size 4096 >> >> bytes, directio = 1 >> > >> > Do you mind capturing an strace?  I''d like to see where that blkdev_fsync >> > is coming from. >> >> Here is an strace. I can see a lot of sync_file_range operations. > > Yeah, these all look like the flusher thread, and shouldn''t be hitting > blkdev_fsync.  Can you confirm that with > >        filestore flusher = false >        filestore sync flush = false > > you get no sync_file_range at all?  I wonder if this is...

...t; ssize_t pread64,pread::__pread(int, void *, size_t, off_t); +<parisc> ssize_t pwrite64,pwrite::__pwrite(int, void *, size_t, off_t); +<!parisc> ssize_t pread64,pread::pread(int, void *, size_t, off_t); +<!parisc> ssize_t pwrite64,pwrite::pwrite(int, void *, size_t, off_t); int sync_file_range,fdatasync,fsync::sync_file_range(int, off_t, off_t, unsigned int); <?> int splice(int, off_t *, int, off_t *, size_t, unsigned int); <?> int tee(int, int, size_t, unsigned int); diff --git a/usr/klibc/pread.c b/usr/klibc/pread.c new file mode 100644 index 0000000..0d8c3b1 --- /dev/nu...

....com/1247135#c29 > > And here you can how unrelated I/O is affected by uncontrolled flushes: > https://bugzilla.redhat.com/1247135#c30 > https://bugzilla.redhat.com/1247135#c36 Thanks for the explanation. Our use of file_flush (ie fdatasync) is less than ideal - we should probably use sync_file_range, which is what Linus suggested. However in this case it won't be a problem because we're only flushing the few pages we have just written. We control the file and there is no chance that the flush will cause an uncontrollable flood of data. The bigger issue to me: Sanlock should really...

...ero is the one which is required. > > FWIW NBD allows you to flush ranges or flush the whole disk, in case > that matters (your proposal only allows you to flush the whole disk). > What is the use case for flushing ranges? I guess we will have one or few flushes per images. Looking at sync_file_range(2), it does not seem to be a safe way to flush: Warning This system call is extremely dangerous and should not be used in portable programs. None of these operations writes out the file's metadata. Therefore, unless the application is strictly performing...

On Wed, Oct 23, 2013 at 03:38:30AM +0100, Pádraig Brady wrote: [...] By the way, Eric Sandeen solved the problem. It's a genuine misfeature in ext4 called auto_da_alloc which causes a flush on close if the file has been truncated (ftruncate or O_TRUNC) and the file size is zero bytes. I added these patches which work around the issue:

On Wed, Mar 14, 2018 at 06:56:19PM +0000, Nir Soffer wrote: > I posted documentation for the new API optimized for random I/O: > https://gerrit.ovirt.org/#/c/89022/ Wish I'd had this documentation when I started the patch :-) Yes, it's much clearer. > I changed POST to PATCH to match the existing /tickets API, and > this also seems to be more standard way to do such

Here's an assortment of build and run-time fixes for various architectures that we've applied in Debian. Ben. Aurelien Jarno (1): ppc64: fix struct stat Ben Hutchings (2): MIPS: Update archfcntl.h syscalls: Override detection of direct socket syscalls on i386, m68k, s390 Helge Deller (1): Add pread and pwrite 32bit syscall wrappers for parisc Mauricio Faria de Oliveira

On Fri, Aug 07, 2020 at 05:29:24PM +0300, Nir Soffer wrote: > On Fri, Aug 7, 2020 at 5:07 PM Richard W.M. Jones <rjones@redhat.com> wrote: > > These ones? > > https://www.redhat.com/archives/libguestfs/2020-August/msg00078.html > > No, we had a bug when copying image from glance caused sanlock timeouts > because of the unpredictable page cache flushes. > > We

...t unfortunately it is considerably > more complex and dangerous than I am comfortable adding to the file > plugin: > > http://lkml.iu.edu/hypermail/linux/kernel/1005.2/01845.html > http://lkml.iu.edu/hypermail/linux/kernel/1005.2/01953.html > > (See also scary warnings in the sync_file_range man page) We can always add more knobs later if someone has a use case and benchmarks for them. I think what you have here is fine. > + > +=item B<fadvise=normal> > + > +=item B<fadvise=random> > + > +=item B<fadvise=sequential> > + > +This optional f...

...to do this without the overhead, but unfortunately it is considerably more complex and dangerous than I am comfortable adding to the file plugin: http://lkml.iu.edu/hypermail/linux/kernel/1005.2/01845.html http://lkml.iu.edu/hypermail/linux/kernel/1005.2/01953.html (See also scary warnings in the sync_file_range man page) --- plugins/file/nbdkit-file-plugin.pod | 44 ++++++++++++++ plugins/file/file.c | 90 +++++++++++++++++++++++++++++ 2 files changed, 134 insertions(+) diff --git a/plugins/file/nbdkit-file-plugin.pod b/plugins/file/nbdkit-file-plugin.pod index dac673ae..0d61b312 100644...

On Mon, Mar 12, 2018 at 2:57 PM Eric Blake <eblake@redhat.com> wrote: > On 03/12/2018 07:13 AM, Nir Soffer wrote: > > On Mon, Mar 12, 2018 at 12:32 PM Richard W.M. Jones <rjones@redhat.com> > > wrote: > > > >> On Mon, Mar 12, 2018 at 07:13:52AM +0000, Nir Soffer wrote: > >>> On Fri, Mar 9, 2018 at 4:25 PM Richard W.M. Jones

...OUND: get_mempolicy SYSCALL FOUND: fchdir SYSCALL FOUND: mlock SYSCALL FOUND: mmap SYSCALL FOUND: send SYSCALL FOUND: utimes SYSCALL FOUND: getcwd SYSCALL FOUND: sched_get_priority_min SYSCALL FOUND: putpmsg SYSCALL FOUND: rt_sigprocmask SYSCALL FOUND: sigreturn SYSCALL FOUND: accept SYSCALL FOUND: sync_file_range2 SYSCALL FOUND: clock_settime SYSCALL FOUND: bind SYSCALL FOUND: sched_yield SYSCALL FOUND: access SYSCALL FOUND: munlock SYSCALL FOUND: dup2 SYSCALL FOUND: dup3 SYSCALL FOUND: pipe SYSCALL FOUND: readdir SYSCALL FOUND: munlockall SYSCALL FOUND: getitimer SYSCALL FOUND: vm86 SYSCALL FOUND: setuid...

On Tue, Aug 20, 2013 at 07:44:39AM +0200, leroy christophe wrote: > > > Find attached two patches I have in order to build klibc 2.0.2 > against kernel 3.8.13 > We had to introduce those patches when going from kernel 3.6 to kernel 3.7 > Hope it helps. > those patches are wrong and again very brittle. just use the way it is described in `make help': A) cd ~/src/linux