[Stgt-devel] stgt backing store & SSC
Thu Aug 2 21:18:13 CEST 2007
On Thu, 2007-08-02 at 14:58 -0400, Pete Wyckoff 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.
also considering tape can have compression and encryption, then each
block is variable size even in fixed size mode. so support variable size
is a must eventually.
> 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.)
> 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
> Stgt-devel mailing list
> Stgt-devel at lists.berlios.de
@#$%^ purging memory... (*!%
More information about the stgt