On Thu, Nov 16, 2017 at 10:15:28 -0500, Jean-Louis Martineau wrote:
> Nathan,
>
> Try this patch.
>
> run: amdump --no-dump --no-flush CONFIG
> Will do all scheduled vault to the vault-storage
[...]
> diff --git a/server-src/driver.c b/server-src/driver.c
> index 351494a..fd01296 100644
> --- a/server-src/driver.c
> +++ b/server-src/driver.c
> @@ -107,6 +107,10 @@ static int taper_started = 0;
> static int nb_storage;
> static cmddatas_t *cmddatas = NULL;
>
> +static int no_dump = FALSE;
> +//static int no_flush = FALSE;
> +static int no_vault = FALSE;
> +
> static int wait_children(int count);
> static void wait_for_children(void);
> static void allocate_bandwidth(netif_t *ip, unsigned long kps);
> @@ -305,6 +309,30 @@ main(
> }
>
> if (argc > 2) {
> + if (g_str_equal(argv[2], "--no-dump")) {
> + no_dump = TRUE;
> + argv++;
> + argc--;
> + }
> + }
I noticed when reviewing the log file from my "amdump --no-dump" run
that there were still "INFO dumper" lines in there, from when the
dumpers start up at the beginning of the run and when they terminate at
the end (with no activity in between).
I wondered if the dumpers should be getting started at all when no_dump
is true, and took a look at driver.c to see how the dumpers were getting
kicked off -- and discovered that driver.c already implements a "nodump"
option, and that indeed if that option is enabled, the dumper processes
are not spawned.
(I see that this "nodump" option is used by Amflush.pm.)
Anyway, I guess the question is whether it makes sense to merge the new
--no-dump and original nodump options for driver.c, at least as far as
having one internal boolean variable to handle both -- or, if not,
if there are any places where the code currently checks for !nodump
where !no_dump should be treated equivalently?
Nathan
----------------------------------------------------------------------------
Nathan Stratton Treadway - [email protected] - Mid-Atlantic region
Ray Ontko & Co. - Software consulting services - http://www.ontko.com/
GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239
Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
