[Stgt-devel] stgt backing store & SSC

[Mark Harvey]

On 8/3/07, Pete Wyckoff <pw at osc.edu> wrote:
> markh794 at gmail.com wrote on Tue, 31 Jul 2007 19:57 +1000:
> > For Variable block SSC device, the block size written needs to be
> > tracked.
> [..]
> > My current thoughts of a solution:
> > ========================
> > A block header describes each block written -> Analogy to the 'tar'
> > format where a header is written, followed by the 'data' followed by
> > another header, followed by more data...repeat...until blank header...
> [..]
> > However the current implementation for iSCSI -> bs_sync uses a
> > pread64()/pwrite64() and writes data based on information stored in
> > scsi_cmd -
> >  pwrite64(fd, cmd->uaddr, cmd->len, cmd->offset)
> >  pread64(fd, cmd->uaddr, cmd->len, cmd->offset)
> >
> >
> > Would it be OK to add a 'blk_header' structure to struct scsi_cmd and if
> > blk_header is set, write this blk header as well ?
> > I will attempt to put the above idea into code and submit for comment...
>
> I think rather than trying to add stuff to existing backing stores
> that you should consider writing your own.  You need to store both
> "metadata" (block descriptors) and data, and none of the BSes are
> set up for that.
>
> The complexity of trying to glue in the blk_header so that all BSes
> know how to tack that on top seems big.  Then you have to tell them
> to read the header, and consider fields in that when determining how
> much further data to read.

>It gets messy fast.

Yep. Got there :)

>
> In the lu_init for the ssc device, you can change the BS.  Then in
> your READ/WRITE command handler, you can make calls into your own
> BS that knows how to store this information.  (Look out for the
> allocation size hack in target.c for TYPE_SPT; you may need
> something similar.)

Thanks for the tip. I was trying to identify the best place to patch
in a modified BS and had not thought of lu_init.

> In general, the current separation of backing store from device only
> really works for block storage.  We need an OSD-only backing store
> for OSD too (not in tree).  May be cleaner just to rid the concept
> of backing store from everything except the device code.
>
>                 -- Pete
>

Regards
Mark