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

[Mark Harvey]

On Thu, Oct 2, 2008 at 8:55 AM, FUJITA Tomonori
<fujita.tomonori at lab.ntt.co.jp> wrote:
> 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.

The format has a narrow focus - to emulate a tape. (sequential
access). Seeking will be slower (compared to Richards) as it has to
seek between blk_headers. Most backup software expect a delay in
seeking. Blk header contains the block number, so a 'report position'
is simple - fixed or variable block size.

I agree that there will be an overhead of reading in the block header,
check for valid blk header, followed by a read of the block of data
and finally check for over/under runs and error processing.

I can't see any real performance issues in the write path. We know the
size, fill in blk header, write blk header, followed by data block and
finally a 'end of data' header blk. (OK - three writes compared to one
write with Richards format.)

Or am I missing the point of your concerns ?

Cheers
Mark
>
>
>> 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