search for: start_t

...eletions(-) diff --git a/mllib/common_utils.ml b/mllib/common_utils.ml index 32e908d..516cff3 100644 --- a/mllib/common_utils.ml +++ b/mllib/common_utils.ml @@ -282,11 +282,11 @@ let verbose () = !verbose (* Timestamped progress messages, used for ordinary messages when not * --quiet. *) -let start_t = Unix.time () +let start_t = Unix.gettimeofday () let message fs = let display str = if not (quiet ()) then ( - let t = sprintf "%.1f" (Unix.time () -. start_t) in + let t = sprintf "%.1f" (Unix.gettimeofday () -. start_t) in printf "[%6s] "...

...: data connection for %s: SSH remote port %d, local port %d\n", @@ -371,6 +380,69 @@ start_qemu_nbd (int port, const char *device) return pid; } +static int +wait_qemu_nbd (int nbd_local_port, int timeout_seconds) +{ + int sockfd; + int result = 0; + struct sockaddr_in addr; + time_t start_t, now_t; + struct timeval timeout = { .tv_usec = 0 }; + char magic[8]; /* NBDMAGIC */ + size_t bytes_read = 0; + ssize_t recvd; + + time (&start_t); + + sockfd = socket (AF_INET, SOCK_STREAM, 0); + if (sockfd == -1) { + perror ("socket"); + return -1; + } + + memset(&amp...

...useable field in R, date and time in a data-frame. The developer says its the number of milliseconds since midnight, January 1, 1970. sample: *1232558018624* --------------------- How do I interpret the time stamp? Is there a date, i need a date and time. site_id,survey_id,version_id,survey_start_ts,survey_question_id,start_ts,end_ts,answer 2,registration,1,1232558018625,z1,*1232558018624*,*1232558266179*,4 Answer: The timestamp is a number representing the exact date and time. it is the number of milliseconds since midnight, January 1, 1970. Are you using it in the DB or R? I am not sure...

...should see 4 failures: +# pread FAILS +# retry and wait 2 seconds +# open FAILS +# retry and wait 4 seconds +# open succeeds +# pread FAILS +# retry and wait 8 seconds +# pread FAILS +# retry and wait 16 seconds +# pread succeeds + +# The minimum time for the test should be 2+4+8+16 = 30 seconds. +start_t=`stat -c '%Z' retry-reopen-fail-start` +end_t=`date +'%s'` +if [ $((end_t - start_t)) -lt 30 ]; then + echo "$0: test ran too quickly" + exit 1 +fi + +# Check the handle was opened 5 times. +retry_open_count=`cat retry-reopen-fail-open-count` +if [ $retry_open_count...

....h> +#include <stdint.h> +#include <string.h> +#include <assert.h> + +#include <pthread.h> + +#include "guestfs.h" +#include "guestfs-utils.h" + +static guestfs_h *g; + +#define RUN_TIME 60 /* seconds */ +#define NR_CONCURRENT_THREADS 4 + +static void *start_thread (void *nullv); + +int +main (int argc, char *argv[]) +{ + time_t start_t, t; + pthread_t threads[NR_CONCURRENT_THREADS]; + void *ret; + int i, r; + + /* Because we rely on error message content below, force LC_ALL=C. */ + setenv ("LC_ALL", "C", 1); + + g = guestfs_cr...

Same as v2, except: - Drop the RUN_OUTPUT_FILE functionality completely. It will be replaced with enhanced .trs files as discussed. - Rebase on head. Rich.

...t 2 seconds > +# open FAILS > +# retry and wait 4 seconds > +# open succeeds > +# pread FAILS > +# retry and wait 8 seconds > +# pread FAILS > +# retry and wait 16 seconds > +# pread succeeds > + > +# The minimum time for the test should be 2+4+8+16 = 30 seconds. > +start_t=`stat -c '%Z' retry-reopen-fail-start` > +end_t=`date +'%s'` > +if [ $((end_t - start_t)) -lt 30 ]; then > + echo "$0: test ran too quickly" > + exit 1 > +fi Slows down 'make check'; is there any way we can scale it to be slightly faster, such...

If you spend your time looking at libguestfs debugging output you'll see many messages from the daemon main loop like this: guestfsd: main_loop: new request, len 0x54 guestfsd: main_loop: proc 278 (mkfs) took 0.02 seconds I don't think these messages really bring much value. This commit removes them entirely. An alternative might be to change them to make them shorter and/or less

This happened on s390 in Koji, once. The key lines from the log are: + start_t=0 nbdkit: sh[1]: debug: retry 1: waiting 1 seconds before retrying nbdkit: sh[1]: debug: retry 1: waiting 1 seconds before retrying + end_t=1 Somehow nbdkit did wait 2 seconds (or at least, nbdkit_nanosleep (1, 0) was called twice by the retry filter). But in the bash script, time (as measured by...

This is an updated and extended version of the original patch: https://www.redhat.com/archives/libguestfs/2010-August/msg00163.html This adds OCaml and Perl bindings (both tested), support for progress bars in virt-resize, and adds progress notifications to a number of the simpler commands. Still to do is to add progress messages to more commands. There are still a few commands which would be

I pushed the (hopefully) completely non-controversial bits upstream: https://github.com/libguestfs/libguestfs/commit/8a72616bf7bc686ad4d033482541fcd73c148b53 https://github.com/libguestfs/libguestfs/commit/b20d36aa1bcabfe1e5eefcf47b727280a6474be8 This patch is what remains. Rich.

...ISED OF THE POSSIBILITY OF +# SUCH DAMAGE. + +source ./functions.sh +set -e +set -x + +requires nbdsh --base-allocation -c 'quit()' + +files="retry-extents-count retry-extents-open-count" +rm -f $files +cleanup_fn rm -f $files + +touch retry-extents-count retry-extents-open-count +start_t=$SECONDS + +# Create a custom plugin which will test retrying. +nbdkit -v -U - \ + sh - \ + --filter=retry retry-delay=1 \ + --run 'nbdsh --base-allocation --uri $uri -c " +entries = [] +def f (metacontext, offset, e, err): + global entries + assert err.value == 0 +...

...iables with no initializers (C guarantees 0-initialization even if you aren't explicit). > +static char *mountpoint, *filename; > +static const char *pidfile; > +static char *fuse_options; > +static struct fuse_chan *ch; > +static struct fuse *fuse; > +static struct timespec start_t; > +static uint64_t size; > + > +static void __attribute__((noreturn)) > +usage (FILE *fp, int exitcode) > +{ > + fprintf (fp, > +" nbdfuse [-r] MOUNTPOINT[/FILENAME] URI\n" Do we want to use any #ifdefs to avoid advertising URI support on the command line when...

...+ +source ./functions.sh +set -e +set -x + +requires nbdsh -c 'i = nbd.CMD_FLAG_FAST_ZERO +exit(not h.supports_uri())' + +files="retry-zero-flags-count retry-zero-flags-open-count" +rm -f $files +cleanup_fn rm -f $files + +touch retry-zero-flags-count retry-zero-flags-open-count +start_t=$SECONDS + +# Create a custom plugin which will test retrying. +nbdkit -v -U - \ + sh - \ + --filter=retry retry-delay=1 \ + --run 'nbdsh --uri $uri -c " +h.zero (512, 0) +try: + h.zero (512, 0, + nbd.CMD_FLAG_FUA | nbd.CMD_FLAG_NO_HOLE | nbd.CMD_FLAG_FAST_Z...

...+ +export sock +nbdsh -c ' +import os +import time + +h.connect_unix (os.environ["sock"]) + +# We should be able to issue multiple requests in parallel, +# and the total time taken should not be much more than 10 seconds +# because all sleeps in the plugin should happen in parallel. +start_t = time.time() +for i in range (10): + buf = nbd.Buffer (512) + h.aio_pread (buf, 0) + +while h.aio_in_flight() > 0: + h.poll(-1) +end_t = time.time() + +t = end_t - start_t +print (t) + +# Since we launched 10 requests, if we serialized on them we +# would have waited at least 100 secon...

...sg; + "timestamp", JSON.String (c_rfc3999_date_time_string ()); + "type", JSON.String msgtype; + ] in + pr "%s\n" (JSON.string_of_doc ~fmt:JSON.Compact json) + (* Timestamped progress messages, used for ordinary messages when not * --quiet. *) let start_t = Unix.gettimeofday () let message fs = let display str = + log_as_json "message" str; if not (quiet ()) then ( let t = sprintf "%.1f" (Unix.gettimeofday () -. start_t) in printf "[%6s] " t; @@ -105,6 +118,7 @@ let message fs = (* Error messa...

On Sun, Aug 02, 2020 at 10:13:05AM +0100, Richard W.M. Jones wrote: > This happened on s390 in Koji, once. The key lines from the > log are: > > + start_t=0 > nbdkit: sh[1]: debug: retry 1: waiting 1 seconds before retrying > nbdkit: sh[1]: debug: retry 1: waiting 1 seconds before retrying > + end_t=1 > > Somehow nbdkit did wait 2 seconds (or at least, nbdkit_nanosleep (1, 0) > was called twice by the retry filter). But in the bas...

v2 was here: https://www.redhat.com/archives/libguestfs/2019-September/msg00221.html I think this is more like "the one". It handles reopen failing correctly, and there is a second test for that. I also ran my sshd tests locally and it worked in all scenarios I could think up (except of course sshd not being available at the start, but we want that to fail). Rich.

...libnbd.h> + +#define MAX_REQUEST_SIZE (64 * 1024 * 1024) + +static struct nbd_handle *nbd; +static bool readonly = false; +static char *mountpoint, *filename; +static const char *pidfile; +static char *fuse_options; +static struct fuse_chan *ch; +static struct fuse *fuse; +static struct timespec start_t; +static uint64_t size; + +static int nbdfuse_getattr (const char *path, struct stat *stbuf); +static int nbdfuse_readdir (const char *path, void *buf, + fuse_fill_dir_t filler, + off_t offset, struct fuse_file_info *fi); +static int nbdfuse_ope...

I think this is my last round of patches for issues I identified with the retry filter. With this in place, it should be safe to interject another filter in between retry and the plugin. Eric Blake (5): retry: Don't call into closed plugin tests: Refactor test-retry-reopen-fail.sh tests: Enhance retry test to cover failed reopen server: Move prepare/finalize/close recursion to