[Stgt-devel] stgt backing store & SSC
Fri Aug 3 02:47:29 CEST 2007
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
More information about the stgt