Re: amflush and .tmp files in holding directory

2017-11-22 Thread Nathan Stratton Treadway
On Wed, Nov 22, 2017 at 09:35:48 -0500, Jean-Louis Martineau wrote:
> We want to flush the .tmp files.
> 
> They are partial dump and they may contains important files, so we want 
> to flush them.
> amrecover never restore from partial dump, but they can be manually 
> restored.

Ah, got it.

In that case, the details from my original email on this thread (dated
Nov 17) become more important, since it seemed like the taper process
crashed while trying to tape the .tmp file.  

When I first saw the errors in the log file I started investigating and
had a theory that the taper program couldn't handle a situation where
the next-chunk referenced in the header of the current file didn't
actually exist, but I did not investigate far enough to confirm that
theory.

Unfortunately the logs from that amflush run have rotated off my system
now, and of course it will be more difficult for me to get amflush to
try flushing .tmp files again now that the pid locking is working, but
let me know if you want me to try to investigate that taper crash further.

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


Re: amflush and .tmp files in holding directory

2017-11-22 Thread Jean-Louis Martineau
Nathan,

We want to flush the .tmp files.

They are partial dump and they may contains important files, so we want 
to flush them.
amrecover never restore from partial dump, but they can be manually 
restored.

Jean-Louis

On 21/11/17 08:33 PM, Nathan Stratton Treadway wrote:
> On Mon, Nov 20, 2017 at 14:42:01 -0500, Jean-Louis Martineau wrote:
> > Each process should take a lock on the holding directory (a pid file),
>
> In my original amflush-during-amdump test the specific error I noticed
> was that amflush attempted to flush .tmp files out of the holding
> disk (which in turn caused the taper process to crash).
>
> The pid-lock fixes will reduce the chance of that problem, but if (for
> example) an amdump process dies and leaves .tmp files in
> the holding disk, I think amflush would still try to flush them.
>
> Would it make sense for
> Amholding.pm:get_files_for_flush()/$each_file_fn() to check the filename
> and skip any that end in ".tmp" (similar to the check that exists in
> holding.c:holding_get_walk_fn() )?
>
> 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
This message is the property of CARBONITE, INC. and may contain confidential or 
privileged information.
If this message has been delivered to you by mistake, then do not copy or 
deliver this message to anyone.  Instead, destroy it and notify me by reply 
e-mail


Re: amflush and .tmp files in holding directory

2017-11-21 Thread Nathan Stratton Treadway
On Mon, Nov 20, 2017 at 14:42:01 -0500, Jean-Louis Martineau wrote:
> Each process should take a lock on the holding directory (a pid file), 

In my original amflush-during-amdump test the specific error I noticed 
was that amflush attempted to flush .tmp files out of the holding
disk (which in turn caused the taper process to crash).

The pid-lock fixes will reduce the chance of that problem, but if (for
example) an amdump process dies and leaves .tmp files in
the holding disk, I think amflush would still try to flush them.

Would it make sense for
Amholding.pm:get_files_for_flush()/$each_file_fn() to check the filename
and skip any that end in ".tmp" (similar to the check that exists in
holding.c:holding_get_walk_fn() )?

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