Coder Social home page Coder Social logo

phobos-storage / phobos Goto Github PK

View Code? Open in Web Editor NEW
3.0 5.0 2.0 7.7 MB

This repository holds the source code for Phobos, a Parallel Heterogeneous Object Store.

License: GNU Lesser General Public License v2.1

Makefile 1.14% Shell 7.87% M4 1.04% C 72.54% Python 10.47% Perl 6.42% PLpgSQL 0.52%

phobos's Introduction

Phobos documentation

Introduction

Phobos, standing for Parallel Heterogeneous OBject Store, is a tool designed to manage large volumes of data for various kinds of storage technologies from SSD to tapes. Phobos can efficiently handle very large datasets on inexpensive media without sacrificing scalability, performance, or fault-tolerance requirements.

Phobos is designed to allow the easy integration of new modules for layouts such as mirroring and erasure coding or, in a near future, I/O adapters.

This document presents basic information about Phobos installation and the first steps of its utilization. More information can be found in the following links:

Installation

Requirements for tape access

You need to install LTFS >= 2.4 to enable phobos access to tapes.

LTFS RPM can be found on IBM Fix Central: ltfs 2.4

You can also retrieve its sources on gihub: https://github.com/LinearTapeFileSystem/ltfs

If you want to build RPMs from these sources, you can find packaging resources (i.e. spec file) for LTFS here: https://github.com/piste2750/rpm-ltfs

Note: since LTFS 2.4, lin_tape driver is no longer needed to access tapes. LTFS now uses the standard linux tape driver (st).

Phobos installation

Install phobos and its requirements:

yum install phobos

Database setup (on RHEL7/CentOS7)

Install postgresql version >= 9.4 (from EPEL or any version compatible with Postgres 9.4):

yum install postgresql94-server postgresql94-contrib

Initialize postgresql directories:

/usr/pgsql-9.4/bin/postgresql94-setup initdb

Edit /var/lib/pgsql/9.4/data/pg_hba.conf to authorize access from phobos host (localhost in this example):

# "local" is for Unix domain socket connections only
local   all             all                                     trust
# IPv4 local connections:
host    all             all             127.0.0.1/32            md5
# IPv6 local connections:
host    all             all             ::1/128                 md5

Start the database server:

systemctl start postgresql-9.4.service

Finally, create phobos database and tables as postgres user (the password for SQL phobos user will be prompted for unless provided with -p):

sudo -u postgres phobos_db setup_db -s

First steps

Launching phobosd

To use phobos, a daemon called phobosd needs to be launched. It mainly manages the drive/media allocation and sets up resources to read or write your data.

To launch/stop the daemon:

# systemctl start/stop phobosd

Scanning libraries

Use the phobos lib scan command to scan a given library. For instance, the following will give the contents of the /dev/changer library:

phobos lib scan /dev/changer

When using the library (such as when running the above command), if phobos returns an "invalid argument" error, and when you check the logs you see the following:

<WARNING> SCSI ERROR: scsi_masked_status=0x1, adapter_status=0, driver_status=0x8
<WARNING>     req_sense_error=0x70, sense_key=0x5 (Illegal Request)
<WARNING>     asc=0x24, ascq=0 (Additional sense: Invalid field in cbd)
<ERROR> Sense key 0x5 (converted to -22): Invalid argument
<ERROR> scsi_element_status failed for type 'drives': Invalid argument

It may be a tape library limitation. For some type of tape libraries, for instance IBM libraries, one can't query a drive's serial number and it's volume label in the same request. To prevent this, phobos can separate the query in two by activating the parameter 'sep_sn_query' in the section 'lib_scsi', as shown here, or as the environment variable 'PHOBOS_LIB_SCSI_sep_sn_query=1'.

Device and media management

Adding drives

Use the phobos command line to add new tape drives to be managed by phobos.

It is recommanded to specify a device path which is persistent after reboot (eg. managed by dev mapper).

By default, drives are added in a locked state, so they are not immediatly used in production.

To enable using a drive in production as soon as it is added, specify the '--unlock' option:

phobos drive add --unlock /dev/mapper/LTO6-012345

Adding media

To add tapes to be managed by phobos, use the phobos command line. It is mandatory to specify a media type (like LTO8, T10KD...) with option -t:

phobos tape add --type lto6 [073200-073222]L6

Note1: this operation requires no access to the medium.

Note2: the set of supported media types, drive types, and compatibility rules between drives and media are configurable. See section 'Configuring device and media types' below for more details.

Once a media has been added, it needs to be formatted. You can optionally unlock the tape when the operation is done, so it becomes usable in production.

phobos tape format --unlock 073200L6

Locking resources

A device or media can be locked. In this case it cannot be used for subsequent 'put' or 'get' operations:

phobos drive {lock|unlock} <drive_serial|drive_path>
phobos media {lock|unlock} <media_id>

Listing resources

Any device or media can be listed using the 'list' operation. For instance, the following will list all the existing tape identifiers:

phobos tape list

Object management

The rest of this document will describe object management using CLI calls. An API is available and is more described here.

Writting objects

When pushing an object you need to specify an identifier that can be later used to retrieve this data.

Phobos also allows specifying an arbitrary set of attributes (key-values) to be attached to the object. They are specified when putting the object using the '-m' option.

# phobos put <file>       <id>      --metadata  <k=v,k=v,...>
phobos put  myinput_file  foo-12345 --metadata  user=$LOGNAME,\
    put_time=$(date +%s),version=1

Reading objects

To retrieve the data of an object, use phobos get. Its arguments are the identifier of the object to be retrieved, as well as a path of target file.

For example:

phobos get obj0123 /tmp/obj0123.back

Reading object attributes

To retrieve custom object metadata, use phobos getmd:

$ phobos getmd obj0123
cksum=md5:7c28aec5441644094064fcf651ab5e3e,user=foo

Deleting objects

To delete an object, use phobos del[ete]:

phobos del obj0123

WARNING: the object will not be completely removed from the phobos system ie. its data will still exist and be accessible. Thus the object is considered as deprecated and basic operations can no longer be executed on it if its uuid/version is not given. A future feature will allow the complete removal of an object.

This deletion can be reverted using phobos undel[ete]:

phobos undel obj0123

To revert an object deletion, the object ID needs not to be used by a living object.

Listing objects

To list objects, use phobos object list:

$ phobos object list --output oid,user_md
| oid   | user_md         |
|-------|-----------------|
| obj01 | {}              |
| obj02 | {"user": "foo"} |

The --output option describes which field will be output. all can be used as a special field to select them all.

phobos's People

Contributors

sebagougeaud avatar valeriyoann avatar patlucas avatar courrierg avatar tl-cea avatar hdoreau avatar ja-cea avatar martinetd avatar phdeniel avatar killerkaninchen avatar gauthierevd avatar thiell avatar vincascea avatar

Stargazers

 avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

Forkers

thiell martinetd

phobos's Issues

TLC: SPOF, current workaround and feature requests

Opening this for discussion and to provide some feedback. The introduction of the TLC is changing the way we manage phobos and adds complexity we did not originally expect.

Before:

  • each data movers could access our SpectraLogic tape library using a separate dev changer device via ADI as needed (one can be configured per drive)
  • a full drive failure with ADI did not impact the whole system (it only affected the phobosd instances accessing it)
  • a specific phobosd instance was not able to automatically switch to another lib_device (that limitation is still present with the TLC, see below)

Now, with the TLC being mandatory at this time, we are facing new challenges:

  • only a single TLC instance can be accessed from all data movers at a specific time, because of caching involved at the TLC level
  • it looks like the TLC configuration in phobos.conf only supports a single changer device, like phobosd before, but it is even more problematic now.

Our goal is to not have a single point of failure when accessing the library. We currently cannot have multiple TLCs accessed at the same time by multiple phobosd because of the local caching performed by the TLC. Our current workaround to a TLC SPOF is to set up a virtual IP using keepalived.service on a set of multiple data movers each running a TLC service, like this:

/etc/keepalived/keepalived.conf:

! Configuration File for keepalived

vrrp_instance TLC_VI_1 {
    state BACKUP
    interface eno8303
    virtual_router_id 51
    priority 255
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass ...
    }
    virtual_ipaddress {
        10.2.0.199/24
    }
    notify_master ...
    notify_backup ...
    notify_fault ...
}

With elm-ent-tlc set to 10.2.0.199, we then use the following in phobos.conf to configure the tlc service:

[tlc]
hostname = elm-ent-tlc
port = 20123
lib_device = /dev/sch0

However:

  • (1) because of the caching that each TLC daemon is doing, we cannot easily migrate the TLC IP to another data mover live. But at least it should work in case of the crash of the server running the TLC: the virtual IP immediately moves to another TLC which can answer requests. Having a way to disable all caching done by the TLC would be welcome here.

  • (2) correct me if I am wrong but a specific TLC instance seems to only supports a single lib_device, so if we loose access to the changer device used by the TLC, the TLC does not work anymore and all phobosd will be stuck. As a workaround to this, we configure each TLC service with a different lib_device and have a local daemon testing the tlc, but it's cumbersome. It would be nice if the TLC could manage multiple changer devices and switch to a working one automatically.

Hope that makes sense, let me know what you think!

phobos tape format only uses local drives?

With the current master branch, I noticed that phobos tape format only uses the drives configured for the local server (where the command is run from). We have 4 data movers, each with 4 drives configured in Phobos, and I have the following configuration:

[io_sched_tape]
read_algo = grouped_read
write_algo = fifo
format_algo = fifo

dispatch_algo = fair_share
# Minimum number of LTO9 drives for read, write and formats respectively
fair_share_LTO9_min = 0,0,0
# Maximum number of LTO9 drives for read, write and formats respectively
fair_share_LTO9_max = 16,16,16

Without read/write going on, as fair_share_LTO9_max for format is set to 16, it should use all 4 drives per data movers (16 total), however only the tape drives from the local server are considered (currently_dedicated_to switches to "F" but not for the other servers). If I launch phobos tape format from another server, then its local drives are used to format and they work.

I think it used to work with 1.95.1 (not 100% sure though). Not critical as format is relatively rare but I wanted to raise the issue.

phobosd segfault when formatting tape if drive model not found in config

I think there's a problem with init not failing early when the model is not found?

Trying to format a tape with a bad config segfaults as follow:

(gdb) bt
#0  0x00007fb4a0cbc58b in __strcmp_avx2 () from /usr/lib64/libc.so.6
#1  0x00007fb4a1092f95 in msort_with_tmp () from /usr/lib64/libglib-2.0.so.0
#2  0x00007fb4a1092f23 in msort_with_tmp () from /usr/lib64/libglib-2.0.so.0
#3  0x00007fb4a10957cd in msort_r () from /usr/lib64/libglib-2.0.so.0
#4  0x000055cc541da244 in fair_share_number_of_requests (_devices=<optimized out>, 
    io_sched_hdl=0x55cc54d90920) at io_schedulers/device_dispatch_algorithms.c:775
#5  fair_share_number_of_requests (io_sched_hdl=0x55cc54d90920, _devices=<optimized out>)
    at io_schedulers/device_dispatch_algorithms.c:747
#6  0x000055cc541d81b1 in io_sched_dispatch_devices (devices=<optimized out>, 
    io_sched_hdl=0x55cc54d90920) at /usr/src/debug/phobos-1.95.1-2.el9.x86_64/src/lrs/io_sched.c:109
#7  lrs_sched_thread (sdata=<optimized out>)
    at /usr/src/debug/phobos-1.95.1-2.el9.x86_64/src/lrs/lrs_sched.c:2823
#8  0x00007fb4a0c9f802 in start_thread () from /usr/lib64/libc.so.6
#9  0x00007fb4a0c3f450 in clone3 () from /usr/lib64/libc.so.6

The actual crash is because ld_technology is NULL in sort_devices_by_technology_cmp()
I think we should fail any such drives early e.g. make lrs_dev_technology() fail, but didn't take the time to dig into this yet as it was more of a configuration problem.

Source address X of drive element at address Y does not correspond to any existing element.

Using phobos 2.0, I often see the following error message in the logs:

<ERROR> Source address '0xXXXX' of drive element at address '0xYYY' does not correspond to any existing element. We will search a free slot address to move.: Cannot assign requested address (99)

Example with phobos drive unload 10130057FB:

Jun 10 17:36:08 elm-ent-dm01 phobosd[10729]: 2024-06-10 17:36:08.779861000 <INFO> umount: medium '058160L9' in device '/dev/sg11' mounted at '/mnt/phobos-sg11'
Jun 10 17:36:08 elm-ent-dm01 systemd[1]: mnt-phobos\x2dsg11.mount: Deactivated successfully.
Jun 10 17:36:21 elm-ent-dm01 ltfs[19125]: 4ab5 LTFS17235I Writing index of 058160 to a (Reason: Unmount, 174 files) 10140057FB.
Jun 10 17:36:29 elm-ent-dm01 ltfs[19125]: 4ab5 LTFS17236I Wrote index of 058160 (Gen = 23, Part = a, Pos = 5, 10140057FB).
Jun 10 17:36:29 elm-ent-dm01 ltfs[19125]: 4ab5 LTFS11034I Volume unmounted successfully.
Jun 10 17:36:29 elm-ent-dm01 ltfs[19125]: 4ab5 LTFS30252I Logical block protection is disabled.
Jun 10 17:36:29 elm-ent-dm01 tlc[3159]: 2024-06-10 17:36:29.904212000 <ERROR> Source address '0x1278' of drive element at address '0x103' does not correspond to any existing element. We will search a free slot address to move.: Cannot assign requested address (99)

The umount is successful though, in this case the tape was moved to 0x1269:

slot: address=0x1269 source_address=0x103 volume='058160L9' accessible full
slot: address=0x1278 accessible
drive: address=0x103 device_id='10140057FB' accessible

Is this something to worry about? Could it be that Phobos is not properly tracking the source of the tape?

RFC: fair_share_max per tag

I believe we would greatly benefit from having limits of (local) drives that can be use but per specific tag.

Similarly to:

# Maximum number of LTO9 drives for read, write and formats respectively
fair_share_LTO9_max = 4,4,4

...but by tag :)

Note: for fair_share by tag, format would not be relevant, only drives for read and write.

Our use case is as follow: we have tapes with different/disjoint tags (for example: n0, n1, n2, n3) , and we are archiving files to all of them at the same time. We would like to have something like

# fair_share_max[<tag>] = <max_drives_read>,<max_drives_write>
fair_share_max[n0] = 1,1
fair_share_max[n1] = 1,1
fair_share_max[n2] = 1,1
fair_share_max[n3] = 1,1

So that for any tape mounted containing tag "n0", 3 other drives could remain available for the other tags.
What do you think?

phobos drive del and scsi reservation

Really minor but reporting just to not forget: our LTO-9 drives are accessible from multiple hosts, and when deleting a drive with phobos drive del ... from a host and adding it to another with phobos drive add ..., then this drive won't work and LTFS complains about an existing SCSI reservation.

When phobosd is trying to use the drive from the other server, we can see errors like that:

Nov 09 21:41:35 elm-ent-dm02 phobosd[64958]: 2023-11-09 21:41:35.853830000 <VERBOSE> fdcb LTFS30250I Opened the SCSI tape device 1.0.2.0 (/dev/sg4).
Nov 09 21:41:35 elm-ent-dm02 phobosd[64958]: 2023-11-09 21:41:35.853838000 <VERBOSE> fdcb LTFS30207I Vendor ID is IBM     .
Nov 09 21:41:35 elm-ent-dm02 phobosd[64958]: 2023-11-09 21:41:35.853843000 <VERBOSE> fdcb LTFS30208I Product ID is ULTRIUM-TD9     .
Nov 09 21:41:35 elm-ent-dm02 phobosd[64958]: 2023-11-09 21:41:35.853849000 <VERBOSE> fdcb LTFS30214I Firmware revision is Q3F4.
Nov 09 21:41:35 elm-ent-dm02 ltfs[64971]: fdcb LTFS30250I Opened the SCSI tape device 1.0.2.0 (/dev/sg4).
Nov 09 21:41:35 elm-ent-dm02 phobosd[64958]: 2023-11-09 21:41:35.853855000 <VERBOSE> fdcb LTFS30215I Drive serial is 10210057FB.
Nov 09 21:41:35 elm-ent-dm02 ltfs[64971]: fdcb LTFS30207I Vendor ID is IBM     .
Nov 09 21:41:35 elm-ent-dm02 ltfs[64971]: fdcb LTFS30208I Product ID is ULTRIUM-TD9     .
Nov 09 21:41:35 elm-ent-dm02 phobosd[64958]: 2023-11-09 21:41:35.853915000 <VERBOSE> fdcb LTFS30285I The reserved buffer size of /dev/sg4 is 1048576.
Nov 09 21:41:35 elm-ent-dm02 ltfs[64971]: fdcb LTFS30214I Firmware revision is Q3F4.
Nov 09 21:41:35 elm-ent-dm02 ltfs[64971]: fdcb LTFS30215I Drive serial is 10210057FB.
Nov 09 21:41:35 elm-ent-dm02 ltfs[64971]: fdcb LTFS30285I The reserved buffer size of /dev/sg4 is 1048576.
Nov 09 21:41:35 elm-ent-dm02 ltfs[64971]: fdcb LTFS30205I RSOC (0xa3) returns -20601.
Nov 09 21:41:35 elm-ent-dm02 phobosd[64958]: 2023-11-09 21:41:35.854879000 <VERBOSE> fdcb LTFS30205I RSOC (0xa3) returns -20601.
Nov 09 21:41:35 elm-ent-dm02 phobosd[64958]: 2023-11-09 21:41:35.854892000 <VERBOSE> fdcb LTFS30263I RSOC returns Not Ready to Ready Transition, Medium May Have Changed (-20601) /dev/sg4.
Nov 09 21:41:35 elm-ent-dm02 phobosd[64958]: 2023-11-09 21:41:35.854901000 <VERBOSE> fdcb LTFS30262I Forcing drive dump.
Nov 09 21:41:35 elm-ent-dm02 phobosd[64958]: 2023-11-09 21:41:35.854906000 <VERBOSE> fdcb LTFS39802W Unknown SCSI OP code 0x1d, use default timeout.
Nov 09 21:41:35 elm-ent-dm02 ltfs[64971]: fdcb LTFS30263I RSOC returns Not Ready to Ready Transition, Medium May Have Changed (-20601) /dev/sg4.
Nov 09 21:41:35 elm-ent-dm02 ltfs[64971]: fdcb LTFS30262I Forcing drive dump.
Nov 09 21:41:35 elm-ent-dm02 ltfs[64971]: fdcb LTFS39802W Unknown SCSI OP code 0x1d, use default timeout.
Nov 09 21:41:35 elm-ent-dm02 kernel: st 1:0:2:0: Mode parameters changed
Nov 09 21:41:35 elm-ent-dm02 ltfs[64971]: fdcb LTFS30205I FORCE_DUMP (0x1d) returns -20604.
Nov 09 21:41:35 elm-ent-dm02 phobosd[64958]: 2023-11-09 21:41:35.860636000 <VERBOSE> fdcb LTFS30205I FORCE_DUMP (0x1d) returns -20604.
Nov 09 21:41:35 elm-ent-dm02 phobosd[64958]: 2023-11-09 21:41:35.860655000 <VERBOSE> fdcb LTFS30263I FORCE_DUMP returns Mode Parameters Changed (-20604) /dev/sg4.
Nov 09 21:41:35 elm-ent-dm02 phobosd[64958]: 2023-11-09 21:41:35.860662000 <VERBOSE> fdcb LTFS30262I Forcing drive dump.
Nov 09 21:41:35 elm-ent-dm02 phobosd[64958]: 2023-11-09 21:41:35.860668000 <VERBOSE> fdcb LTFS39802W Unknown SCSI OP code 0x1d, use default timeout.
Nov 09 21:41:35 elm-ent-dm02 ltfs[64971]: fdcb LTFS30263I FORCE_DUMP returns Mode Parameters Changed (-20604) /dev/sg4.
Nov 09 21:41:35 elm-ent-dm02 ltfs[64971]: fdcb LTFS30262I Forcing drive dump.
Nov 09 21:41:35 elm-ent-dm02 ltfs[64971]: fdcb LTFS39802W Unknown SCSI OP code 0x1d, use default timeout.
Nov 09 21:41:35 elm-ent-dm02 kernel: st 1:0:2:0: reservation conflict
Nov 09 21:41:35 elm-ent-dm02 ltfs[64971]: fdcb LTFS30205I FORCE_DUMP (0x1d) returns -21719.

Especially this one I guess:

Nov 09 21:41:35 elm-ent-dm02 kernel: st 1:0:2:0: reservation conflict

A solution is to release the SCSI reservation on the original server with the following command:

# ltfs -o release_device -o devname=/dev/sg4 
126e LTFS14000I LTFS starting, LTFS version 2.4.5.1 (Prelim), log level 2.
126e LTFS14058I LTFS Format Specification version 2.4.0.
126e LTFS14104I Launched by "ltfs -o release_device -o devname=/dev/sg4".
126e LTFS14105I This binary is built for Linux (x86_64).
126e LTFS14106I GCC version is 11.3.1 20221121 (Red Hat 11.3.1-4).
126e LTFS17087I Kernel version: Linux version 5.14.0-284.25.1.el9_2.x86_64 ([email protected]) (gcc (GCC) 11.3.1 20221121 (Red Hat 11.3.1-4), GNU ld version 2.35.2-37.el9) #1 SMP PREEMPT_DYNAMIC Wed Aug 2 14:53:30 UTC 2023 i386.
126e LTFS17089I Distribution: Rocky Linux release 9.2 (Blue Onyx).
126e LTFS17089I Distribution: NAME="Rocky Linux".
126e LTFS17089I Distribution: Rocky Linux release 9.2 (Blue Onyx).
126e LTFS17089I Distribution: Rocky Linux release 9.2 (Blue Onyx).
126e LTFS14063I Sync type is "time", Sync time is 300 sec.
126e LTFS17085I Plugin: Loading "sg" tape backend.
126e LTFS17085I Plugin: Loading "unified" iosched backend.
126e LTFS14095I Set the tape device write-anywhere mode to avoid cartridge ejection.
126e LTFS30209I Opening a device through sg-ibmtape driver (/dev/sg4).
126e LTFS30250I Opened the SCSI tape device 1.0.2.0 (/dev/sg4).
126e LTFS30207I Vendor ID is IBM     .
126e LTFS30208I Product ID is ULTRIUM-TD9     .
126e LTFS30214I Firmware revision is Q3F4.
126e LTFS30215I Drive serial is 10210057FB.
126e LTFS30285I The reserved buffer size of /dev/sg4 is 1048576.
126e LTFS30294I Setting up timeout values from RSOC.
126e LTFS17160I Maximum device block size is 1048576.
126e LTFS12022I Unloading medium.
126e LTFS30252I Logical block protection is disabled.

After that, the drive can be used from the other server by phobos.

Perhaps phobos drive del could do that automatically? Or a note in the documentation about that would be less confusing.

TLC: buffer too small

We're testing the latest master branch and hit the following problem when enabling the TLC:

[root@elm-ent-dm02 ~]# phobos lib scan
2024-05-01 11:40:51,480 <ERROR> Requested buffer size is too large: Bad message
2024-05-01 11:40:51,480 <ERROR> Cannot receive response from TLC: Bad message
2024-05-01 11:40:51,480 <ERROR> Unable to send/recv status request to tlc: Bad message
2024-05-01 11:40:51,480 <ERROR> Failed to scan library for path '/dev/sch1': Bad message
2024-05-01 11:40:51,480 <ERROR> [Errno -74] Failed to scan the library /dev/sch1, will abort 'lib scan'

LOG_GOTO(err, rc = -EBADMSG, "Requested buffer size is too large");

The TLC gets the request and sends 54,181 bytes (I saw it by stracing it), which is bigger than the max buffer length on the receiving side:

./src/communication/comm.c:48:#define MAX_RECV_BUF_SIZE (16*1024LL)

If I increase it to 256*1024LL it seems to work fine, but for how long if we add more tapes?

Confusing error message in case of single tape format failure

I noticed something minor but confusing. When formatting multiple tapes at once (a "tape set"!), I had a drive still with a previous device reservation and phobos was not able to use it, and this failed the format for one tape, however, the command returned an error for all tapes.

[root@elm-ent-dm01 ~]# phobos tape list -T p-test | xargs phobos tape format
2024-05-16 18:57:10,001 <INFO> Formatting media '[057621-057623,057629,057644-057646,057655]L9'
2024-05-16 19:00:59,570 <ERROR> Format failed for medium '057629L9': Input/output error
2024-05-16 19:09:38,858 <ERROR> Failed to format every medium in '[057621-057623,057629,057644-057646,057655]L9' (Input/output error)

"every" here is confusing to me. Maybe the error message should be "Failed to format some medium in ..." ?

Just to confirm, we can see that format had actually failed for only one tape (057629L9):

|   addr_type | adm_status   | delete_access   | family   | get_access   | lock_hostname   |   lock_owner | lock_ts                    | model   | name     | put_access   | tags                     | fs.type   | fs.status   | fs.label   |   stats.nb_obj | stats.logc_spc_used   | stats.phys_spc_used   | stats.phys_spc_free   |   stats.nb_load |   stats.nb_errors |   stats.last_load || 

|           1 | unlocked     | True            | tape     | True         | None            |            0 | 0                          | LTO9    | 057621L9 | True         | ['mr', 'p-test', 'n3']   | LTFS      | empty       | 057621L9   |              0 | 0.0B                  | 0.0B                  | 17.1TB                |               0 |                 0 |                 0 |
|           1 | unlocked     | True            | tape     | True         | None            |            0 | 0                          | LTO9    | 057622L9 | True         | ['mr', 'p-test', 'n1']   | LTFS      | empty       | 057622L9   |              0 | 0.0B                  | 0.0B                  | 17.1TB                |               0 |                 0 |                 0 |
|           1 | unlocked     | True            | tape     | True         | None            |            0 | 0                          | LTO9    | 057623L9 | True         | ['mr', 'p-test', 'n2']   | LTFS      | empty       | 057623L9   |              0 | 0.0B                  | 0.0B                  | 17.1TB                |               0 |                 0 |                 0 |
|           1 | failed       | True            | tape     | True         | None            |            0 | 0                          | LTO9    | 057629L9 | True         | ['mr', 'p-test', 'n0']   | LTFS      | blank       | NULL       |              0 | 0.0B                  | 0.0B                  | 0.0B                  |               0 |                 0 |                 0 |
|           1 | unlocked     | True            | tape     | True         | None            |            0 | 0                          | LTO9    | 057644L9 | True         | ['mr', 'p-test', 'n3']   | LTFS      | empty       | 057644L9   |              0 | 0.0B                  | 0.0B                  | 17.1TB                |               0 |                 0 |                 0 |
|           1 | unlocked     | True            | tape     | True         | None            |            0 | 0                          | LTO9    | 057645L9 | True         | ['mr', 'p-test', 'n2']   | LTFS      | empty       | 057645L9   |              0 | 0.0B                  | 0.0B                  | 17.1TB                |               0 |                 0 |                 0 |
|           1 | unlocked     | True            | tape     | True         | None            |            0 | 0                          | LTO9    | 057646L9 | True         | ['mr', 'p-test', 'n1']   | LTFS      | empty       | 057646L9   |              0 | 0.0B                  | 0.0B                  | 17.1TB                |               0 |                 0 |                 0 |
|           1 | unlocked     | True            | tape     | True         | None            |            0 | 0                          | LTO9    | 057655L9 | True         | ['mr', 'p-test', 'n0']   | LTFS      | empty       | 057655L9   |              0 | 0.0B                  | 0.0B                  | 17.1TB                |               0 |                 0 |                 0 |

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.