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

[ronnie sahlberg]

I think that for MMC there is very little metadata that would be nice to have.
I think MMC could benefit from storing (feature 0x0109) MediaSerialNumber
maybe also barcode (if used with SMC as a dvd jukebox) and possibly other
MAM attributes as well.

I think none of these are that important really (a lot of DVD players
can not return feature 0x0109 anyway :-) )

It would be nice to store MediaSerialNumber and also a Barcode
together with the "image" file for MMC.
I dont know how much other MAM data that applications using a MMC
jukebox expects/require for the jukebox functionality to work.

Since "iso image" is a "standard/common" fileformat for storing
"images of CD/DVD disks" and a lot of tools exist for using
such iso images,   I think it would be attractive if our "images" were
compatible, which kind of requires that we do not store this metadata
in the filedata itself.
Extended attributes would be one possible avenue to store this
metadata without "polluting" hte data and make us incompatible.


SSC is different.
First it likely requires a LOT of metadata. Second, I dont think there
is a de-facto standard   or tools   to operate on a "raw-tape-image"
anyway
so there shouldnt be anything that the images have to be compatible
with in the first place.


The biggest question for "how much metadata does MMC need" would
probably be when combined with SMC into a jukebox.
I have no idea how much/what metadata that a jukebox controller
program wants/needs to be happy.


On Tue, May 6, 2008 at 2:59 PM, FUJITA Tomonori
<fujita.tomonori at lab.ntt.co.jp> wrote:
> On Sat, 3 May 2008 16:23:56 +1000
> "ronnie sahlberg" <ronniesahlberg at gmail.com> wrote:
>
>> 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)". )
>
> As you said, we need to consider both the pros and cons of using
> metadata. People are happy to give up the compatibily and use virtual
> disk images (like QCOW, VMDK, and VHD) for snapshot. I think that just
> for something trivial like serial number is not a good idea. Does the
> metadata give something huge for mmc and ssc (like snapshot for sbc)?
>