[Stgt-devel] Store persistent media data in extended attributes?
ronnie sahlberg
ronniesahlberg
Sat May 3 08:23:56 CEST 2008
Cool.
How far is you ssc? can one do basic i/o with say mt with it?
While SSC is very different,
in MMC I would like to be able to store things like a barcode,
serialnumber, and other MAM and MAM-like data attached to the backing
store file.
I want it to be stored in a was so that this data is "attached" to the
file that contains the actual image of the media.
I dont want to use separate files to store the metadata, so extended
attributes would be a nice way to associate the metadata with the
actual data.
In MMC I think it would also have value if the actual file itself,
reading all data from position 0 to the end of file would be an
identical image of the data
of the disk itself. I.e. the file content IS the actual .ISO of the
disk. Which would allow such files holding a STGT MMC backingstore
to be mountable as
a ISO9660 filesystem through loopback and also be immediately
compatible and work with the myriad of "Virtual/Phantom DVD Drive"
applications
and drivers on other systems.
This compatibility would fail for me if I store metadata at the
beginning of the file.
(Yeah, you can mount the file as an .ISO but you have to strip off
the first xMByte of the file first :-( compared to "the file is just
a normal .ISO image so its compatible with anything under the sun (but
it also has some invisible extra metadata stored at the side)". )
This, desire to be compatible with other apps that expect a file to be
a raw .ISO image would of course not exist for SSC. So my desire in
how to implement
this metadata store is different from yours.
While SSC constraints probably forces you to embedd at least some
metadata intermixed with the actual data (by the way is there even
such a thing that could conceptually be described as a "raw" tape
image anyway? :-) )
Some of the SSC metadata wouldnt make sense to split out from the file
data, other metadata is probably impossible to split out from the file
data.
But, some metadata, such as serial number and barcode's could be.
It would be great if we could store some of this metadata in a way
that is consistent across all device types SSC MMC and others so we
can share code and implementation.
got to run ...
regards
ronnie sahlberg
On Sat, May 3, 2008 at 3:56 PM, Mark Harvey <mark_harvey at symantec.com> wrote:
> 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
>
More information about the stgt
mailing list