From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <pbs-devel-bounces@lists.proxmox.com> Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 1BA551FF17C for <inbox@lore.proxmox.com>; Wed, 16 Apr 2025 08:22:39 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 534731DB10; Wed, 16 Apr 2025 08:22:37 +0200 (CEST) Message-ID: <1c0e52bb-5bb9-4dcd-a196-654bc99b8ecb@proxmox.com> Date: Wed, 16 Apr 2025 08:22:33 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta To: Thomas Lamprecht <t.lamprecht@proxmox.com>, Proxmox Backup Server development discussion <pbs-devel@lists.proxmox.com> References: <20250415114043.2389789-1-d.csapak@proxmox.com> <169c3b16-ef44-47fd-a074-da06ba3a8e64@proxmox.com> Content-Language: en-US From: Dominik Csapak <d.csapak@proxmox.com> In-Reply-To: <169c3b16-ef44-47fd-a074-da06ba3a8e64@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL 0.022 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. 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. [hpe.com] Subject: Re: [pbs-devel] [PATCH proxmox-backup] tape: wait for calibration of LTO-9 tapes 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> Reply-To: Proxmox Backup Server development discussion <pbs-devel@lists.proxmox.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: pbs-devel-bounces@lists.proxmox.com Sender: "pbs-devel" <pbs-devel-bounces@lists.proxmox.com> On 4/15/25 17:51, Thomas Lamprecht wrote: > (re-send with list in CC, sorry) > > On 15/04/2025 13:40, Dominik Csapak wrote: >> Since LTO-9, initial loading of tapes into a drive can block up to 2 >> hours according to the spec. In case we run into a ready check timeout, >> query the drive, and increase the timeout to 2 hours and 5 minutes if >> it's calibrating (5 minutes headroom). > > Is there any (spec) reference we can link here? To my knowledge the LTO spec is not published in a standard format like e.g. other RFC or such, but one can find the IBM and HP LTO SCSI references rather easily [0][1] as for the timeout, IBM says it only in their recommendations: > Although most optimizations will complete within 60 minutes some optimizations may take up to 2 hours. and HP: > Media initialization adds a variable amount of time to the initialization process that typically takes between 20 minutes and 2 hours. So it seems there not a hard limit and depends... In my tests it always took around the 1 hour mark (on available hardware here) > > And the 2h5m would be on top of the previous max_wait, AFAICT. > no actually. i overwrite the old 'max_wait' variable and we calculate from the same start point (with start.elapsed()) we only check if that is greater than the timeout, so I increase *to* 2h5m > And, didn't we already fix something like this? Or at least had some > other handling added for long initial initialisation of LTO9 tapes, or > was that something different or just a discussion without a patch. > Not really important though, just wondering. Sorry I should have added more context to the commit message. We did in fact increase the timeout, but only for long formatting, and put a section in the docs explaining the initialization and that it's recommended to do that beforehand with the vendor tools (IMHO it still is even with this patch) Still, forum users encountered timeout issues e.g. when using barcode labeling and not initializing beforehand, so I thought adding a general handling for that in the 'wait_until_ready' (where most of the timeouts from this will occur) makes sense to decrease the friction of the UX (even if it takes longer to finish). > > Changes look alright besides of those meta things, so I could fleece > any relevant info into the commit message too on applying, if nothing > else comes up. > thanks! 0: IBM LTO-9 https://www.ibm.com/support/pages/system/files/inline-files/LTO%20SCSI%20Reference_GA32-0928-05%20(EXTERNAL)_0.pdf 1: HP LTO-9 https://support.hpe.com/hpesc/public/docDisplay?docId=sd00001239en_us&page=GUID-D7147C7F-2016-0901-0921-000000000450.html _______________________________________________ pbs-devel mailing list pbs-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel