From: Dominik Csapak <d.csapak@proxmox.com>
To: pbs-devel@lists.proxmox.com
Subject: [pbs-devel] [PATCH proxmox-backup] tape: fix encryption on certain tape drives
Date: Mon, 15 Dec 2025 14:59:44 +0100 [thread overview]
Message-ID: <20251215135951.2827702-1-d.csapak@proxmox.com> (raw)
For most SCSI commands, we have to preallocate a buffer for sg_utils to
write into, and the SCSI commands get the buffer size as parameter so
that the tape know how much data it can send.
It seems that some tape drives only allow aligned buffer sizes, though
it's not clear if it has to aligned to 512 or 4096 bytes.
In case of the tape encryption pages, we used 8192 + 4 bytes for some
reason, which tripped those tape drives up and they returned an error
instead of valid data.
Every other instance of our commands use aligned buffer sizes, so use
them here too to increase compatibility.
Tested on our LTO9 tape changer, which works with both values correctly.
This was encountered by a customer in an enterprise ticket.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
---
pbs-tape/src/sg_tape/encryption.rs | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/pbs-tape/src/sg_tape/encryption.rs b/pbs-tape/src/sg_tape/encryption.rs
index c24a6c658..9390dff7d 100644
--- a/pbs-tape/src/sg_tape/encryption.rs
+++ b/pbs-tape/src/sg_tape/encryption.rs
@@ -134,7 +134,7 @@ fn sg_spout_set_encryption<F: AsRawFd>(
// Warning: this blocks and fails if there is no media loaded
#[allow(clippy::vec_init_then_push)]
fn sg_spin_data_encryption_status<F: AsRawFd>(file: &mut F) -> Result<Vec<u8>, Error> {
- let allocation_len: u32 = 8192 + 4;
+ let allocation_len: u32 = 8192;
let mut sg_raw = SgRaw::new(file, allocation_len as usize)?;
@@ -163,7 +163,7 @@ fn sg_spin_data_encryption_status<F: AsRawFd>(file: &mut F) -> Result<Vec<u8>, E
// Warning: this blocks and fails if there is no media loaded
#[allow(clippy::vec_init_then_push)]
fn sg_spin_data_encryption_caps<F: AsRawFd>(file: &mut F) -> Result<Vec<u8>, Error> {
- let allocation_len: u32 = 8192 + 4;
+ let allocation_len: u32 = 8192;
let mut sg_raw = SgRaw::new(file, allocation_len as usize)?;
--
2.47.3
_______________________________________________
pbs-devel mailing list
pbs-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel
next reply other threads:[~2025-12-15 13:59 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-15 13:59 Dominik Csapak [this message]
2025-12-16 8:10 ` [pbs-devel] applied: " 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=20251215135951.2827702-1-d.csapak@proxmox.com \
--to=d.csapak@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.