all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: Dominik Csapak <d.csapak@proxmox.com>
To: Dietmar Maurer <dietmar@proxmox.com>,
	Proxmox Backup Server development discussion
	<pbs-devel@lists.proxmox.com>
Subject: Re: [pbs-devel] [PATCH proxmox-backup] api2/tape/backup: wait indefinitely for lock in scheduled backup jobs
Date: Thu, 18 Mar 2021 10:25:19 +0100	[thread overview]
Message-ID: <02dea46e-870d-a3b8-fa72-d7e5bca5a7ee@proxmox.com> (raw)
In-Reply-To: <1769832677.243.1616046831798@webmail.proxmox.com>

On 3/18/21 06:53, Dietmar Maurer wrote:
>> -    // early check/lock before starting worker
>> -    let drive_lock = lock_tape_device(&drive_config, &setup.drive)?;
>> +    // for scheduled jobs we acquire the lock later in the worker
>> +    let drive_lock = if schedule.is_some() {
>> +        None
>> +    } else {
>> +        Some(lock_tape_device(&drive_config, &setup.drive)?)
>> +    };
> 
> What is the reason for the different locking times? Can't we always lock
> later in the worker?
> 

yes we can, but for the non-scheduled backup, we only have one try
to lock and i did not want to start a task since that would generate
a task entry that was preventable by checking beforehand

On 3/18/21 07:04, Dietmar Maurer wrote:
 >
 >> +            let (job_result, summary) = match try_block!({
 >> +                if schedule.is_some() {
 >> +                    // for scheduled tape backup jobs, we wait 
indefinitely for the lock
 >> +                    task_log!(worker, "waiting for drive lock...");
 >> +                    loop {
 >> +                        if let Ok(lock) = 
lock_tape_device(&drive_config, &setup.drive) {
 >> +                            drive_lock = Some(lock);
 >> +                            break;
 >> +                        } // ignore errors
 >
 > I would prefer to add a timeout parameter to lock_tape_device() call.
 > The question is if the lock call gets interrupted by task abort?

i did it this way, because an abort would not trigger if we are just 
waiting on a lock, so i decided to try the lock in a loop with
the check_abort()? call below (so one can abort this)

we could ofc add a timeout parameter, but would not change
the code here (and currently has no real upside, since
we probably would not use different timeouts anyway?)

 >
 >> +
 >> +                        worker.check_abort()?;
 >> +                    }
 >> +                }
 >> +                set_tape_device_state(&setup.drive, 
&worker.upid().to_string())?;




  reply	other threads:[~2021-03-18  9:25 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-17 13:38 Dominik Csapak
2021-03-18  5:53 ` Dietmar Maurer
2021-03-18  9:25   ` Dominik Csapak [this message]
2021-03-18  6:04 ` Dietmar Maurer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=02dea46e-870d-a3b8-fa72-d7e5bca5a7ee@proxmox.com \
    --to=d.csapak@proxmox.com \
    --cc=dietmar@proxmox.com \
    --cc=pbs-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal