From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 ; 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 ; 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 ; 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 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 >> --- >> 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 { >> + >> + 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 { >> - 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