IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
It seems some changers are setting the PVolTag/AVolTag flags in the
ELEMENT STATUS page response, but don't include the actual fields then.
To make it work with such changers, downgrade the errors to warnings, so
we can continue to decode the remaining data.
This is OK since one volume tag is optional and the other is skipped
anyway.
Reported in the forum:
https://forum.proxmox.com/threads/hpe-storeonce-vtl.152547/
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Add tracing logger to all client binaries and remove env_logger.
The reason for this change is twofold: our migration to tracing, and the
behavior when the client calls an api handler directly. Currently the
proxmox-backup-manager calls the api handlers directly for some
commands. This results in no output (on console and task log), as no
tracing logger is instantiated.
Signed-off-by: Gabriel Goller <g.goller@proxmox.com>
since that leads to errors that we don't currently catch before we
reach the regular early warning on tape.
This can be read/set by the Device Configuration Extension Mode Page.
ignore errors on reading or writing, since it may not be available on
LTO-4
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
The product name is Proxmox Backup Server, not just Backup Server,
that makes no sense on its own and it really cannot be expected by
tools extracting any Medium Auxiliary Memory (MAM) info to render it
as `${app_vendor} ${app_name}`.
Drop the comment about ignoring errors, that's pretty clear with
the only-log-error construct.
Instead, add some comments about what the hex numbers refers too and
what their respective length (limit) is. The names where taken from
Table 315 "MAM Host type attributes" in the "IBM LTO SCSI Reference"
for LTO 9.
Slightly off-topic: The tape code really is a mess with sprinkling
those hex numbers hard coded all over the place, often with some
unchecked coupling in other places (like here, the list of set MAM
attrs and the one that get cleared can easily get out of sync..), but
that's for another time to clean-up (I need to cut a release).
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
namely:
Vendor: Proxmox
Name: Backup Server
Version: current running package version
User Label Text: the label text
Media Pool: the current media pool
write it on labeling and when writing a new media-set to a tape.
While we currently don't use this info for anything, this can help users
to identify tapes, even with different backup software.
If we need it in the future, we can e.g. make decisions based on these
fields (e.g. the version).
On format, delete them again.
Note that some VTLs don't correctly delete the attributes from the
virtual tapes.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Some MAM attributes are of type 'TEXT' that is not only ascii, but
controlled by an addition field that specifies various 8bit text
formats.
For now, simply assume utf8 as the default is ascii, and we don't expect
any data that is not ASCII anyway.
This will be needed when we'll want to write those attributes.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Since we don't query each drives status seperately, but rely on a single
call to the drives listing parameter for that, we now add the option
to query the activity there too. This makes that data avaiable for us
to show in a seperate (by default hidden) column.
Also we show the activity in the 'State' column when the drive is idle
from our perspective. This is useful when e.g. an LTO-9 tape is loaded
the first time and is calibrating, since that happens automatically.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
when the tape drive has an activity (and the tape is in motion), certain
calls block until the operation is finished. Since we cannot predict how
long it's going to be and it can be quite long in certain cases,
skip those calls when the drive is doing anything.
If we cannot determine the activity, try to do the queries.
We have to extend the check for a loaded drive in the UI, since the
position is not available during any activity.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
we use the VHF part from the DT Device Activity page for that.
This is intended to query the drive for it's current state and activity.
Currently only the activity is parsed and used.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Fixes the clippy lint
```
warning: accessing first element with `self.transports.get(0)`
--> pbs-tape/src/lib.rs:283:9
|
283 | / self.transports
284 | | .get(0)
| |___________________^ help: try: `self.transports.first()`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#get_first
= note: `#[warn(clippy::get_first)]` on by default
```
Signed-off-by: Maximiliano Sandoval <m.sandoval@proxmox.com>
by introducing an 'assert_encryption_mode' that checks the desired
state, and bails out if it's different, called directly where we
previously set the encryption mode (which is now done automatically)
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
[ TL: add drive_ prefix and fleece in comment ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
For security, we want to automatically unload the encryption key from
the drive when we're done, so there was a Drop handler for SgTape that
handles that. Sadly, our tool we use to set it in the first place, also
invoked the Drop handler, thus unloading the keys again immediately
To fix that, move the Drop handler one logical level higher to the
LtoTapeHandle, which is not used by the 'sg-tape-cmd'.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Prepares for the use in sg-tape-cmd, since we want to use the SgTape
directly instead of LtoTapeHandle.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
rename the inner 'set_encryption' in sg_tape to drive_set_encryption,
so that it's a bit clearer where it comes from.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
allocation length for read element status is a 3 byte field, but it
seems some changers only look at the bottom two bytes. Since we used
0x010000 for it, those changers did not return any data and the calls
failed.
To work around it, request one byte less (0xFFFF) which should still be
enough for the data, but should now work with those buggy
implementations.
Reported by a user in the forum: https://forum.proxmox.com/threads/137391/
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
instead of wrapping the function body in a 'try_block', simply move the
map_err to the only call site, where we can even add more context than
in the function itself.
aside from better error output, no functional change intended
this could help in debugging cases like this issue reported in the forum:
https://forum.proxmox.com/threads/137391/
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
starting with LTO9, a FORMAT(04h) command also reinitializates the tape,
which can take up to tw hours. Since we don't actually want to do that
every time we format, use 'erase_media' when we want a fast erase.
(On a slow erase, we let it run and wait until the drive is ready
again).
The users have to pre-initializate the tapes before using it for them to
work properly though.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
instead of hardcodign the default timeout as only option. This will come
in handy when we need to wait for LTO9+ initialization that can take up
to two hours.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
some libraries (e.g. Qualstar) don't support the DVCID bit in the READ
ELEMENT (B8) command (to return vendor/model of connected drives), so
make that part optional if it fails. We only ever use the serial number
in the `pmtx` tool, so there is not much downside to not having this.
This increases compatibility with such libraries
Reported in the forum:
https://forum.proxmox.com/threads/cant-query-tape-robot-status.131833/
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Fixed a few rustdoc warnings. Converted some 'html'-links to
intra-doc-links and surrounded paths with '`'.
Signed-off-by: Gabriel Goller <g.goller@proxmox.com>
It's needlessly adding mental complexity to always have to translate
usages like info.0 or info.1 in ones head when reading the code.
Transforming this to a struct allows for using descriptive names when
accessing the specific fields and allows for implementing a
constructor per MamFormat, reducing the resulting MAM attribute list
by quite a few lines.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
We already saw that quite some tape libraries/loaders/... ain't
always _that_ standard conform, and even if it'd be guaranteed, it
just makes no sense to create a potential for panicking the whole
daemon due to some sub-features hiccup, rather go for actual error
handling...
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
replacable to replaceable
the field 'field_replacable_unit_code' is not currently used anywhere
descriptior to descriptor
Resuqest to Request
and flags2 to flags3 (the number indicates the numbering of the field
and it's the third field, not the second)
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
there are tape drives (esp. virtual ones) that don't implement the
10-byte variants of MODE SENSE/SELECT. Since the pages we set/request
are never bigger than 255 bytes anyway, we can implement a fallback
with the 6 byte variant here.
Implementing this as a fallback to make sure that existing working
drives keep the existing implementation.
Tested with Starwind VTL.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Dietmar Maurer <dietmar@proxmox.com>
080Ch: it's binary not ascii, and the length is not specified
(hp says 23-n bytes)
0820h and 0821h are also binary and not ascii
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
besides harmonizing versions, the only global change is that the tokio-io
feature of pxar is now implied since its default anyway, instead of being
spelled out.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
pbs-buildcfg is the only one that needs to inherit the version as well, since
it stores it in the compiled crate.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
