[Stgt-devel] Store persistent media data in extended attributes?

[Mark Harvey]

Hello Ronnie,

A few months ago, I started on an SSC module. However I have failed to
find the spare time to get a working proof of concept to post.... I
still hope to finish this.


I was embedding this information within the backing store of the virtual
media disk file...
e.g.
struct MAM {
        uint32_t tape_fmt_version;

        uint64_t remaining_capacity;
        uint64_t max_capacity;
        uint64_t TapeAlert;
        uint64_t load_count;
[snip]
};

#define BLK_NOOP                0x00000000
#define BLK_UNCOMPRESS_DATA     0x00000001
#define BLK_COMPRESSED_DATA     0x00000002
#define BLK_ENCRYPTED_DATA      0x00000004
#define BLK_BOT                 0x00000010
#define BLK_EOD                 0x00000020
#define BLK_FILEMARK            0x00000040
#define BLK_FILEMARK_DATA       0x00001000

struct blk_header {
        uint32_t blk_type;
        uint32_t blk_size;
        uint32_t disk_blk_size;
        loff_t blk_number;
        loff_t prev_blk;
        loff_t curr_blk;
        loff_t next_blk;
};

The virtual media disk layout of :

struct blk_header (BLK_BOT)
struct MAM
struct blk_header (block 0)
<disk_blk_size> block of data
struct blk_header (block 1)
<disk_blk_size> block of data
(repeat for n blocks)
struct blk_header (block n+1)
<disk_blk_size> block of data
struct blk_header (BLK_EOD)

The prev_blk, curr_blk & next_blk form pointers to previous, current &
next block of data (poor man's double linked list - if you like).


The 'blk_size' & disk_blk_size relates to uncompressed data block size &
size of data block within the virtual media.

Initially I tried keeping this 'metadata' separate from the disk blocks
of data. However this did not work with variable block reads & writes,
as I could not easily determine when a short (or long) block read was
attempted.

The Extended attributes information is kept within the MAM data
structure (total bytes read / written during media life time, total
mounts, media type, mdia serial number etc)

Cheers
Mark Harvey


-----Original Message-----
From: stgt-devel-bounces at lists.berlios.de
[mailto:stgt-devel-bounces at lists.berlios.de] On Behalf Of ronnie
sahlberg
Sent: Saturday, May 03, 2008 3:26 PM
To: stgt-devel at lists.berlios.de
Subject: [Stgt-devel] Store persistent media data in extended
attributes?

List,

Please comment.

A lot of SCSI device types contain a lot of persistent metadata.

Some of these would be the medium auxiliary memory that is accessed by
SPC : READ/WRITE ATTRIBUTE which is available for many device types.

SMC contains things such as SEND VOLUME TAG.

Many device types contain mode page settings, settable from the
initiator and which are supposed to be "persistent" across power and
unload/load cycles.
For example SSC : WORM settings.

UnitSerialNumber which all medias provide is similar, once I have
specified the USN to a device, to me it would make sense if this USN
would be persistent so next time I
export that file as a SCSI device, it should automatically use the
same USN that was previously attached to the device.
Example:
tgtadm --lld iscsi --mode logicalunit --op update --tid $TID --lun
$LUN  --params scsi_sn=FRED00,scsi_id=Fred
Wouldnt it make sense that once this command is issued, the sn and the
id is stored persistently with that backing store file   so that they
apply automagically
next time this volume is exported?
I.e.   you specify/set the serial number once, and it remains
persistent for the remainder of the lifetime of the backing store file
itself. Not having to reapply the setting every single time
you startup tgtd again.

For MMC and SSC devices, this could include things like the barcode
for the media.

For SSC it could also include the metadata such as where the filemark
markers are. (there is a lot of metadata required in ssc).


Would it make sense to implement some smallish API to attach these
kinds of metadata to extended attributes attached to the backing store
file?


regards
ronnie sahlberg
_______________________________________________
Stgt-devel mailing list
Stgt-devel at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/stgt-devel