From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <d.csapak@proxmox.com>
Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits))
 (No client certificate requested)
 by lists.proxmox.com (Postfix) with UTF8SMTPS id CEF9760DF8
 for <pbs-devel@lists.proxmox.com>; Wed,  2 Dec 2020 14:58:14 +0100 (CET)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
 by firstgate.proxmox.com (Proxmox) with UTF8SMTP id C1E7E1C767
 for <pbs-devel@lists.proxmox.com>; Wed,  2 Dec 2020 14:58:14 +0100 (CET)
Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com
 [212.186.127.180])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits))
 (No client certificate requested)
 by firstgate.proxmox.com (Proxmox) with UTF8SMTPS id 8D37B1C758
 for <pbs-devel@lists.proxmox.com>; Wed,  2 Dec 2020 14:58:13 +0100 (CET)
Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1])
 by proxmox-new.maurer-it.com (Proxmox) with UTF8SMTP id 52F92447FE;
 Wed,  2 Dec 2020 14:58:13 +0100 (CET)
To: Wolfgang Bumiller <w.bumiller@proxmox.com>
Cc: pbs-devel@lists.proxmox.com
References: <20201202131957.17051-1-d.csapak@proxmox.com>
 <20201202131957.17051-2-d.csapak@proxmox.com>
 <20201202135000.nxcyky5lhnxddi6a@wobu-vie.proxmox.com>
From: Dominik Csapak <d.csapak@proxmox.com>
Message-ID: <57c91b8c-ef08-2b28-595c-20db7cb8d8da@proxmox.com>
Date: Wed, 2 Dec 2020 14:58:12 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:84.0) Gecko/20100101
 Thunderbird/84.0
MIME-Version: 1.0
In-Reply-To: <20201202135000.nxcyky5lhnxddi6a@wobu-vie.proxmox.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-SPAM-LEVEL: Spam detection results:  0
 AWL 0.300 Adjusted score from AWL reputation of From: address
 KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
 NICE_REPLY_A           -0.001 Looks like a legit reply (A)
 RCVD_IN_DNSWL_MED        -2.3 Sender listed at https://www.dnswl.org/,
 medium trust
 SPF_HELO_NONE           0.001 SPF: HELO does not publish an SPF Record
 SPF_PASS               -0.001 SPF: sender matches SPF record
 URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See
 http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more
 information. [datastore.rs]
Subject: Re: [pbs-devel] [PATCH proxmox-backup 2/2] backup/datastore: move
 manifest locking to /run
X-BeenThere: pbs-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox Backup Server development discussion
 <pbs-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pbs-devel>, 
 <mailto:pbs-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pbs-devel/>
List-Post: <mailto:pbs-devel@lists.proxmox.com>
List-Help: <mailto:pbs-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel>, 
 <mailto:pbs-devel-request@lists.proxmox.com?subject=subscribe>
X-List-Received-Date: Wed, 02 Dec 2020 13:58:14 -0000

On 12/2/20 2:50 PM, Wolfgang Bumiller wrote:
> On Wed, Dec 02, 2020 at 02:19:57PM +0100, Dominik Csapak wrote:
>> this fixes the issue that on some filesystems, you cannot recursively
>> remove a directory when you hold a lock on a file inside (e.g. nfs/cifs)
>>
>> it is not really backwards compatible (so during an upgrade, there
>> could be two daemons have the lock), but since the locking was
>> broken before (see previous patch) it should not really matter
>> (also it seems very unlikely that someone will trigger this)
>>
>> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
>> ---
>>   src/backup/datastore.rs | 26 +++++++++++++++++++++++---
>>   1 file changed, 23 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/backup/datastore.rs b/src/backup/datastore.rs
>> index 0f74ac3c..9cc88906 100644
>> --- a/src/backup/datastore.rs
>> +++ b/src/backup/datastore.rs
>> @@ -257,6 +257,12 @@ impl DataStore {
>>                   )
>>               })?;
>>   
>> +        // the manifest does not exists anymore, we do not need to keep the lock
>> +        if let Ok(path) = self.manifest_lock_path(backup_dir) {
>> +            // ignore errors
>> +            let _ = std::fs::remove_file(path);
>> +        }
>> +
>>           Ok(())
>>       }
>>   
>> @@ -698,13 +704,27 @@ impl DataStore {
>>           ))
>>       }
>>
> 
> please describe the path in a doc comment here

ok, but even in a private api?

> 
>> +    fn manifest_lock_path(
>> +        &self,
>> +        backup_dir: &BackupDir,
>> +    ) -> Result<PathBuf, Error> {
>> +
>> +        let mut path = PathBuf::from("/run/proxmox-backup/.locks/");
> 
> why `.locks` and not just `locks`? I don't see the benefit in "hidden"
> files in `/run`?

yeah you're right, no sense in making this hidden

> 
>> +        path.push(self.name());
>> +        path.push(backup_dir.group().backup_type());
>> +        path.push(backup_dir.group().backup_id());
>> +        std::fs::create_dir_all(&path)?;
> 
> Is there a particular reason you use a `PathBuf` here this way? Looks
> like you could just `format!()` it all the same? Since none of these
> types are `Path`s to begin with anyway.
> 
> Since those components are all strings, IMO you could work with a
> `String` from the start and only convert to PathBuf at the end.
> 
> Would save you the extra String allocation below.

ok will do

> 
> So if I see this right, the file will then be
> /run/proxmox-backup/.locks/$store/${type}/${id}/${timestamp}.index.json.lck
> 
> seems reasonable apart from the dot in `.locks` ;-)
> 
> However, do we really need the directory structure here?
> Shouldn't a flat `.../locks/${type}.${id}.${timestamp}.index.json` be
> fine as well? (I don't really mind, it would just be less code ;-) )

for now, ids do not really have a length limit besides the fs filename 
limit of 255 bytes
and since i had to factor that out, i did for datastore/type as well
(would look even weirder to use something like:
.../locks/${datastore}.${type}/${id}/${timestamp}.index.json.lck
)

though we probably should limit the id length anyway...

> 
>> +
>> +        path.push(format!( "{}{}", backup_dir.backup_time_string(), &MANIFEST_LOCK_NAME));
>> +
>> +        Ok(path)
>> +    }
>> +
>>       fn lock_manifest(
>>           &self,
>>           backup_dir: &BackupDir,
>>       ) -> Result<File, Error> {
>> -        let mut path = self.base_path();
>> -        path.push(backup_dir.relative_path());
>> -        path.push(&MANIFEST_LOCK_NAME);
>> +        let path = self.manifest_lock_path(backup_dir)?;
>>   
>>           // update_manifest should never take a long time, so if someone else has
>>           // the lock we can simply block a bit and should get it soon
>> -- 
>> 2.20.1