[stgt] [PATCH 0/2] RFC - Double-linked list backing store.

FUJITA Tomonori fujita.tomonori at lab.ntt.co.jp
Thu Oct 2 00:55:51 CEST 2008


On Thu, 2 Oct 2008 08:41:55 +1000
"Mark Harvey" <markh794 at gmail.com> wrote:

> On Wed, Oct 1, 2008 at 10:04 PM, FUJITA Tomonori
> <fujita.tomonori at lab.ntt.co.jp> wrote:
> > On Mon, 18 Aug 2008 15:47:00 +1000
> > Mark Harvey <markh794 at gmail.com> wrote:
> >
> >> An alternative backing store primarily for SSC device which uses a meta-data header for each block of data.
> >>
> >> Embedded with the metadata are forward & back pointers to next & previous headers forming a double-linked list of headers.
> >>
> >> Patch 1/2 patch includes bs_tape and a couple of helper utilities for:
> >> - creating 'blank' media
> >> - Dumping media headers
> >> Patch 2/2 patches the tgt-core-test script which I use to setup the VTL.
> >>
> >> Note: The bs_tape is almost at the same level of functionality as the bs_ssc without Richard Sharps recent patches.
> >>
> >>
> >> Pros: (I can see) of the embedded metadata headers include the ability to store variable data sizes (compressed, encrypted or just variable block writes). Metadata headers do not have to contain data (FILEMARKS, SETMARKS, End of Data markers etc). Not limited by preallocated structure at media creation time.
> >>
> >> Cons: Custom format (i.e. can't use with ISO images)
> >
> > Sorry for the late response, I finally read both your and Richard's
> > patches. I'm not sure yet we should store data and metada in a single
> > file (as your patch) or have a separate metadata (as Richard's one).
> >
> > Your file format is something like:
> >
> > blk_header + fixed-size data + blk_header + fixed-size data ...
> >
> >
> > What's your plan about how to handle the variable-block transfers?
> >
> The actual data 'block size' is stored within each blocks blk_header.
> Both original size + size stored on disk is saved as they may differ
> due to backing store applying compression/encryption.

Yeah, I know that. But I'm not still not sure how we can handle the
variable-block transfers quickly with the format.


> Work still needs to be done on the actual 'write_' op codes to support
> variable block & on 'read_' op codes to correctly return sense data on
> block size mis-matches - Illegal Length Indicator bit.
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



More information about the stgt mailing list