Hi all, not sure if anyone is still around in this group with a bit of tape background?

I am trying to emulate a tape system. Works quite well, but I'm lost on the details of emulating the MAM chip.

In LTO-5 and up, tapes can be partitioned. The commands to access the MAM chip (Read/Write Attribute) allow you to specify a partition as well.

What I cannot deduct from the T10 standards and SCSI reference manuals, is what attributes to return for any particular partition. Only a few of them are specific to a partition, but the specs claim that the drive returns all attributes (starting with x).

Several attributes can be interpreted as belonging to the entire tape (lifetime read/written), but could be per partition as well. Others are clearly per tape (mfg date, serial no).

Anyone around who can shed a light on this topic?

Thanks,
Rob

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

scsirob wrote:

Hi all, not sure if anyone is still around in this group with a bit
of tape background?

I am trying to emulate a tape system. Works quite well, but I'm lost
on the details of emulating the MAM chip.

In LTO-5 and up, tapes can be partitioned. The commands to access the
MAM chip (Read/Write Attribute) allow you to specify a partition as
well.

AFAIK all LTO media (back to LTO1) have a builtin MAM.
Looking at the manuals of 15 year old LTO1/2 drives shows that there
is MAM support and the READ ATTRIBUTE and WRITE ATTRIBUTE commands
already present.

What I cannot deduct from the T10 standards and SCSI reference
manuals, is what attributes to return for any particular partition.
Only a few of them are specific to a partition, but the specs claim
that the drive returns all attributes (starting with x).

Just to be sure that we are talking about the same things:
You want to create/emulate a SCSI target device according to SSC that implements the optional READ ATTRIBUTE and WRITE ATTRIBUTE commands
according to SPC?

Several attributes can be interpreted as belonging to the entire tape (lifetime read/written), but could be per partition as well.
Others are clearly per tape (mfg date, serial no).

Can you tell a bit more about what you want to do. Do you want to
emulate a specific LTO drive (if yes, which one?) or do you want
to create a generic tape emulation with support for partitions?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, 11 February 2018 12:42:12 UTC+1, Michael Bäuerle wrote:

AFAIK all LTO media (back to LTO1) have a builtin MAM.
Looking at the manuals of 15 year old LTO1/2 drives shows that there
is MAM support and the READ ATTRIBUTE and WRITE ATTRIBUTE commands
already present.

That's correct.

What I cannot deduct from the T10 standards and SCSI reference
manuals, is what attributes to return for any particular partition.
Only a few of them are specific to a partition, but the specs claim
that the drive returns all attributes (starting with x).

Just to be sure that we are talking about the same things:
You want to create/emulate a SCSI target device according to SSC that implements the optional READ ATTRIBUTE and WRITE ATTRIBUTE commands
according to SPC?

Correct as well.

Several attributes can be interpreted as belonging to the entire tape (lifetime read/written), but could be per partition as well.
Others are clearly per tape (mfg date, serial no).

Can you tell a bit more about what you want to do. Do you want to
emulate a specific LTO drive (if yes, which one?) or do you want
to create a generic tape emulation with support for partitions?

I'm trying to make a fairly generic emulation for LTO, STK T10K and IBM TS11xx drives (and then some others). I am then trying to copy as many attributes from a physical device, and emulate those on my virtual device.

The issue I run into, is with for instance LTFS-formatted tapes. A Read Attribute for the host attribute 0x802h (application version) returns ASCII text "3.0.0", for both partition 0 and partition 1. What I cannot find is if my emulation needs to
maintain separate copies for each partition, or that there's some way to mark this attribute as 'global' so one copy shows up in all partitions.

The point is that some attributes do seem to be global. The load counter, tape manufacturer data, tape serial number etc are present in all partitions. Some others appear to be maintained on a per-partition base. I'm trying to be as close as possible to
the real thing, but can't figure out if there is a way to tell global attributes apart from per-partition ones.

Thanks,
Rob

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

scsirob wrote:

On Sunday, 11 February 2018 12:42:12 UTC+1, Michael Bäuerle wrote:

scsirob wrote:

[...]
Several attributes can be interpreted as belonging to the entire tape (lifetime read/written), but could be per partition as well.
Others are clearly per tape (mfg date, serial no).

Can you tell a bit more about what you want to do. Do you want to
emulate a specific LTO drive (if yes, which one?) or do you want
to create a generic tape emulation with support for partitions?

I'm trying to make a fairly generic emulation for LTO, STK T10K and
IBM TS11xx drives (and then some others). I am then trying to copy as
many attributes from a physical device, and emulate those on my
virtual device.

The issue I run into, is with for instance LTFS-formatted tapes.
A Read Attribute for the host attribute 0x802h (application version)
returns ASCII text "3.0.0", for both partition 0 and partition 1.
What I cannot find is if my emulation needs to maintain separate
copies for each partition, or that there's some way to mark this
attribute as 'global' so one copy shows up in all partitions.

In general the attribute data should be partition specific (because
the READ ATTRIBUTE and WRITE ATTRIBUTE have a "PARTITION NUMBER"
field in their CDBs). In the case of host attributes 0x0800, 0x0801
and 0x0802 this makes sense, because every partition can be used by
a different application client. For host attribute 0x0809 the name
"PARTITION USER TEXT LABEL" already defines it as partition specific.

The point is that some attributes do seem to be global. The load
counter, tape manufacturer data, tape serial number etc are present
in all partitions. Some others appear to be maintained on a per-
partition base. I'm trying to be as close as possible to the real
thing, but can't figure out if there is a way to tell global
attributes apart from per-partition ones.

SPC4 specifies attribute ranges in Table 346 like this:
|
| Table 346 -- MAM attribute identifier range assignments
|
| Attribute Identifiers Attribute Type Standardized Subclause
| -----------------------------------------------------------------
| 0000h to 03FFh Device Yes 7.3.2.2
| 0400h to 07FFh Medium Yes 7.3.2.3
| 0800h to 0BFFh Host Yes 7.3.2.4
| 0C00h to 0FFFh Device Vendor specific
| 1000h to 13FFh Medium Vendor specific
| 1400h to 17FFh Host Vendor specific
| 1800h to FFFFh Reserved

I would implement the emulation in a way that every attribute can
be partition-specific in general. An internal "global" flag can be
used to avoid storing non-partition specific data multiple times.

The medium type attributes all look global (Table 351). Therefore at
least the range 0400h to 07FFh may have this "global" flag set.


Maybe the general design should allow for multiple volumes too (because
there is also a "VOLUME NUMBER" field in the CDB). I'm not sure if such
media exist in reality (multiple volumes with a shared MAM).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, 4 March 2018 12:25:50 UTC+1, Michael Bäuerle wrote:

I would implement the emulation in a way that every attribute can
be partition-specific in general. An internal "global" flag can be
used to avoid storing non-partition specific data multiple times.

The medium type attributes all look global (Table 351). Therefore at
least the range 0400h to 07FFh may have this "global" flag set.

Thanks Michael. That's what I thought as well. I've implemented it this way and LTFS appears to be happy with my emulation.

Rob

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)