similar to: [nbdkit] [filter/nozero] large binary size with GCC 9

On Fri, 2019-07-05T08:04-0500, Eric Blake wrote: > On 7/4/19 1:38 PM, Thomas Weißschuh wrote: > > In filter/nozero a 64M large, static, zeroed, read-only array is declared. > > The new behavior of GCC puts this array as-is into the binary inflating the > > size by a factor of around 10000. > > Odd that you are only seeing this for the nozero filter, since we also >

On 7/4/19 1:38 PM, Thomas Weißschuh wrote: > Hi all, > > It seems GCC 9 does not put read-only zero-initialized variables into the BSS > section anymore; instead it is put into RODATA. > (See the thread at [0], especially [1]) > Thanks for the pointers. > In filter/nozero a 64M large, static, zeroed, read-only array is declared. > The new behavior of GCC puts this array

On Fri, 2019-07-05T08:48-0500, Eric Blake wrote: > On 7/5/19 8:21 AM, Thomas Weißschuh wrote: > > On Fri, 2019-07-05T08:04-0500, Eric Blake wrote: > >> On 7/4/19 1:38 PM, Thomas Weißschuh wrote: > >>> In filter/nozero a 64M large, static, zeroed, read-only array is declared. > >>> The new behavior of GCC puts this array as-is into the binary inflating the

It may be useful to test whether the client's use of NBD_CMD_FLAG_NO_HOLE makes a difference; do this by adding a mode to --filter=nozero to force a non-trimming zero write. Signed-off-by: Eric Blake <eblake@redhat.com> --- filters/nozero/nbdkit-nozero-filter.pod | 19 +++++++---- filters/nozero/nozero.c | 45 ++++++++++++++++++++----- tests/test-nozero.sh

Another couple things I noticed that are worth improving, but aren't strictly related to implementing fast zero support. Eric Blake (2): server: Assert sane error responses nozero: More efficient FUA handling filters/nozero/nozero.c | 17 +++++++++++-- server/filters.c | 56 +++++++++++++++++++++++++++++++++-------- server/protocol.c | 32 +++++++++++++++++------ 3 files

The nozero filter can split a large request with FUA into several smaller requests; optimize whether the FUA flag is passed on to the next layer based on whether FUA is emulated with flush (only the last write needs it) or is natively supported (every write needs it). Missed in commit df0cc21d. Signed-off-by: Eric Blake <eblake@redhat.com> --- filters/nozero/nozero.c | 17 +++++++++++++++--

On 7/5/19 8:21 AM, Thomas Weißschuh wrote: > On Fri, 2019-07-05T08:04-0500, Eric Blake wrote: >> On 7/4/19 1:38 PM, Thomas Weißschuh wrote: >>> In filter/nozero a 64M large, static, zeroed, read-only array is declared. >>> The new behavior of GCC puts this array as-is into the binary inflating the >>> size by a factor of around 10000. >> >> Odd that

On 7/5/19 9:52 AM, Thomas Weißschuh wrote: >> Good to know. So the fix is indeed removing 'const', rather than >> reducing scope (although I might as well reduce scope while at it, for >> consistency). > > Does this not mean, the 64M are zeroed on every loop iteration in every call to > these functions? No. static variables are guaranteed by the C standard to

Being able to programmatically force nbdkit to be less parallel can be useful during testing. I was less sure about patch 3, but if you like it, I'm inclined to instead squash it into patch 1. This patch is written to apply after my NBD_CMD_CACHE work (since I touched the nocache filter); but can be rearranged if we think this series should go in first while that one undergoes any adjustments

I still need to add testsuite coverage. Perhaps it might be easier if I create a new '--filter=log logfile=foo' filter that produces a log of which commands a client sent, then compare the log using a known client that uses write_zeroes (qemu-io works well) both with and without --filter=nozero to prove that the change in advertisement changes the commands sent over the wire (that would

v4: https://www.redhat.com/archives/libguestfs/2019-January/msg00032.html v5: - Now we set the block size at run time. I'd like to say that I was able to test this change, but unfortunately I couldn't find any easy way to create a filesystem on x86-64 with a block size > 4K. Ext4 doesn't support it at all, and XFS doesn't support block size > page size (and I

On Tue, Jan 23, 2018 at 10:10:12PM -0600, Eric Blake wrote: > I still need to add testsuite coverage. Perhaps it might be easier > if I create a new '--filter=log logfile=foo' filter that produces > a log of which commands a client sent, then compare the log using > a known client that uses write_zeroes (qemu-io works well) both > with and without --filter=nozero to prove

After more than a month since v2 [1], I've finally got my FUA support series polished. This is all of my outstanding patches, even though some of them were originally posted in separate threads from the original FUA post [2], [3] [1] https://www.redhat.com/archives/libguestfs/2018-January/msg00113.html [2] https://www.redhat.com/archives/libguestfs/2018-January/msg00219.html [3]

Sometimes, it's nice to see what a difference it makes in timing or in destination file size when sparse handling is enabled or disabled. Add a new filter that makes it trivial to disable write zero support. Signed-off-by: Eric Blake <eblake@redhat.com> --- TODO | 2 +- configure.ac | 3 +- docs/nbdkit-filter.pod

v1: https://www.redhat.com/archives/libguestfs/2018-September/msg00024.html v2: https://www.redhat.com/archives/libguestfs/2018-September/msg00034.html v3: - Fixed is_config_key zero length test. - Fixed is_config_key so it uses strspn and is not O(n^2). - Changed >= 1.7 to >= 1.8 in the documentation. Rich.

Remove the need to use file= (and in future other) parameters for many plugins. eg. Using the file plugin becomes: nbdkit file disk.img Rich.

Is there a required Clang and LLVM version one needs to do a ''make xen-dist clang=y''? I recently tried and the process failed. I haven''t begun debugging as I figured I would ask the obvious first. The build failed with the following: ... make[4]: Entering directory `/home/builder/xen-unstable/xen/drivers'' make -f /home/builder/xen-unstable/xen/Rules.mk -C char

v1 was here: https://www.redhat.com/archives/libguestfs/2018-September/msg00024.html v2: - As discussed in the patch review, tighten up the characters permitted in keys. - Update documentation to note that relative paths can be made safe by prefixing with ./ and absolute paths do not need any extra steps. - I pushed patch 1/6 from the v1 series since it was just a trivial

The preferred implementation uses __auto_type, a GCC extension also now supported by Clang. Unfortunately OpenBSD ships with GCC 4.2.1 (from 2007!) which predates this extension by quite a few years, so we have to be able to fall back to a plain macro. --- configure.ac | 20 ++++++++++- common/include/minmax.h | 63 +++++++++++++++++++++++++++++++++++

The preferred implementation uses __auto_type, a GCC extension also now supported by Clang. Unfortunately OpenBSD ships with GCC 4.2.1 (from 2007!) which predates this extension by quite a few years, so we have to be able to fall back to a plain macro. --- configure.ac | 20 ++++++++++- common/include/minmax.h | 63 +++++++++++++++++++++++++++++++++++