[Stgt-devel] Thoughts on vtl filemarks

Albert Pauw apauw
Fri Jul 18 21:27:35 CEST 2008


Richard Sharpe wrote:
>
> Please don't create any such header. Doing so limits the number of
> file marks or the amount of MAM (Media Auxiliary Memory) data you can
> keep.
>
> Please consider using separate files for each virtual tape for this purpose.
>   
I see your point, but moving the virtual tape around is more cumbersome,
as you need to keep the files together, otherwise it will be useless 
without the filemarks.
At least that was my thought behind it.
> In your ssc_lu_init function, zalloc an area to contain per-LU private
> data that you squirrel away in the xxc_p pointer of the struct scsi_lu
> * struct that you are passed.
>
> You can base the name of these extra metadata files off of the name of
> the file already provided in path field of the struct scsi_lu * passed
> in (at least it seems so) or make up a name.
>
> I would suggest one for MAM info so that you can support the differing
> sizes in LTO3 and LTO4, and one for the other metadata (filemarks
> setmarks etc).
>
> Thus the metadata file would be a series of records or fields like:
>
> struct
> {
>    uint8_t type; /* 0 = file mark, 1 = setmark, 2 = record boundary
> for variable length records */
>    uint24_t offsethi;  /* upper 24 bits of the offset allowing for
> 56-bit offsets if you want them  */
>    uint32_t offsetlo;  /* lower 32 bits of the offset */
> }
>
> Some care would probably be needed because the same offset could point
> to a filemark and a setmark and a record boundary (although I am not
> sure if this is the correct way to handle this).
>
> I would think that writing a new filemark should invalidate all after
> it because I suspect that in reality anything that was beyond a new
> filemark is actually damaged.
>   
Yes, good point.



More information about the stgt mailing list