similar to: Aw: Re: rsync remote raw block device with --inplace

More notes about diskrsync <https://github.com/dop251/diskrsync> : (0) It seems to work well and efficiently. The README.md now explains how to install it and it's a lot easier than the script I included in my last note would seem to indicate. (I didn't and still don't know Go.) (1) Effectively, inherently, and non-optionally, diskrsync has rsync's --inplace feature. IOW,

This simply compiles, passes tests, but is only able open a handle. This commit does not contain the full bindings. --- Makefile.am | 2 + configure.ac | 32 +++++ generator/GoLang.ml | 116 ++++++++++++++++++ generator/GoLang.mli | 19 +++ generator/Makefile.am

It was broucht up before indeed: https://lists.samba.org/archive/rsync/2012-June/027680.html On 12/30/18 9:50 PM, devzero--- via rsync wrote: >> There have been addons to rsync in the past to do that but rsync really >> isn't the correct tool for the job. > why not correct tool ? > > if rsync can greatly keep two large files in sync between source and destination >

This simply compiles, passes tests, but is only able open a handle. This commit does not contain the full bindings. --- Makefile.am | 2 + configure.ac | 32 ++++ generator/GoLang.ml | 150 ++++++++++++++++++ generator/GoLang.mli | 19 +++ generator/Makefile.am

> There have been addons to rsync in the past to do that but rsync really > isn't the correct tool for the job. why not correct tool ? if rsync can greatly keep two large files in sync between source and destination (using --inplace), why should it (generally spoken) not also be used to keep two blockdevices in sync ? maybe these links are interesting in that context:

Similar to C, OCaml and Rust, this is not a plugin per se. Instead it's more of a method and set of tests around writing plugins in golang. They are standalone programs that compile into shared objects that nbdkit can then load (so there is no "go plugin" between nbdkit and the user plugin, unlike in scripting languages like Perl). --- plugins/golang/nbdkit-golang-plugin.pod

Hello, when i use libguestfs to ceph rbd by golang, but there has panic: panic: runtime error: cgo argument has Go pointer to Go pointer goroutine 1 [running]: guestfs.(*Guestfs).Add_drive.func11(0xc000010028, 0xcda6a0, 0xc0000d6000, 0xc000090280) /opt/gopath/src/guestfs/guestfs.go:1440 +0xc2 guestfs.(*Guestfs).Add_drive(0xc000010028, 0x7ffd4b5d67ff, 0xd, 0xc00008d9d8, 0x0)

When compiling when an older nbdkit is installed, the build would fail because certain symbols such as .get_ready were not defined: ../../src/libguestfs.org/nbdkit/nbdkit.go:541:8: plugin.get_ready undefined (type _Ctype_struct_nbdkit_plugin has no field or method get_ready) This happens because we were using the installed <nbdkit-plugin.h> rather than the local copy. We don't want

Compiling nbdkit from source when an older nbdkit is installed would fail because certain symbols such as .get_ready are not defined in the (installed) <nbdkit-plugin.h>: ../../src/libguestfs.org/nbdkit/nbdkit.go:541:8: plugin.get_ready undefined (type _Ctype_struct_nbdkit_plugin has no field or method get_ready) Of course we should be compiling against the local include/nbdkit-plugin.h

Add a bash function 'prepend' for intelligently prepending elements to paths. eg: prepend PYTHONPATH "/foo" would set PYTHONPATH to "/foo" or "/foo:<previous-contents-of-PYTHONPATH>" Tested by: (1) Building and testing libguestfs twice: first without libguestfs installed as a system library, and then with it installed. (2) Examining the output of

--- golang/Makefile.am | 7 ++++++- golang/src/libguestfs.org/guestfs/guestfs_100_launch_test.go | 2 ++ 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/golang/Makefile.am b/golang/Makefile.am index a60c9ba..f59488e 100644 --- a/golang/Makefile.am +++ b/golang/Makefile.am @@ -37,6 +37,11 @@ EXTRA_DIST = \ if HAVE_GOLANG +GOFLAGS = +if

--- run.in | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/run.in b/run.in index 8fdf454..438a68c 100755 --- a/run.in +++ b/run.in @@ -140,15 +140,15 @@ export PERL_VALGRIND=1 export PERL_DESTRUCT_LEVEL=2 # For Python. -export PYTHON=@PYTHON@ +export PYTHON="@PYTHON@" prepend PYTHONPATH "$b/python/.libs" prepend PYTHONPATH

When compiling when an older nbdkit is installed, the build would fail because certain symbols such as .get_ready were not defined: ../../src/libguestfs.org/nbdkit/nbdkit.go:541:8: plugin.get_ready undefined (type _Ctype_struct_nbdkit_plugin has no field or method get_ready) This happens because we were using the installed <nbdkit-plugin.h> rather than the local copy. We don't want

On Tue, Apr 21, 2020 at 05:07:43PM +0100, Daniel P. Berrangé wrote: > On Tue, Apr 21, 2020 at 11:44:59AM +0100, Richard W.M. Jones wrote: > > Thanks: Dan Berrangé > > > > XXX UNFINISHED: > > > > - Is using uintptr for the handle a good idea? Plugins must return > > something != 0. In other languages we would allow plugins to > > return an

Thanks: Dan Berrangé XXX UNFINISHED: - Is using uintptr for the handle a good idea? Plugins must return something != 0. In other languages we would allow plugins to return an arbitrary object here, but this is not possible in golang because of lack of GC roots. - Default can_* methods are hard to implement. Ideally we would be able to test if a user plugin implements a

On Sat, Oct 17, 2020 at 08:48:40AM +0100, Richard W.M. Jones wrote: > [Adding libguestfs mailing list] > > I reproduced it locally - the difference was installing "gcc-go". > I only had golang-bin installed previously. With gcc-go installed: > > ../run go install libguestfs.org/libnbd > write of Go pointer 0xc000016060 to non-Go memory 0x7f5fe8297390 >

Hello everybody! First, allow me to wish you all a Happy New year! I have a problem with a small app that I wrote in Go and which uses libvirt go bindings. Actually, the problem exists only when I want to compile the code statically. Basically, when CGO_ENABLED=0 is exported, go (running go test, go run, go build) complains: undefined: libvirt.NewConnect When I try to compile the source

It would be very nice to be able to rsync the raw data content of, e.g., a non-mounted disk partition, particularly in combination with --inplace. Our reality: several dual-boot machines running Windows during the day and Linux at night, during backups. Windows is very tedious and iffy to re-reinstall without a raw disk image to start from. Disks fail, and the ensuing downtime must be

On Sat, Oct 17, 2020 at 09:00:30AM +0100, Richard W.M. Jones wrote: >On Sat, Oct 17, 2020 at 08:48:40AM +0100, Richard W.M. Jones wrote: >> [Adding libguestfs mailing list] >> >> I reproduced it locally - the difference was installing "gcc-go". >> I only had golang-bin installed previously. With gcc-go installed: >> >> ../run go install

These bindings get as far as running very simple connections. However there are many missing parts still: * No callbacks. * No functions which handle buffers (pread/pwrite!) This is posted just for general early interest, not even for review. Rich.