[Stgt-devel] Further problems with the SSC code ...
Sat Jul 26 23:52:01 CEST 2008
Remember that SSC takes two types of read/write parameters. Both with
and without specifying the block no.
See the mmc_info in mmc emulation for a way to attach commandset
specific data to the lun, and how to use it.
mmc uses this to remember what the current_profile is and how to write
to a dvd+r.
You may need to store the current block# here to track the read/write
commands with implicit address modes
As others have said as well, you may also encapsulate each block
read/written with a header that specifies
the size of the block, some flags etc.
Or, please make bs_rdwr() take a block index instead of an offset so
that it may be easier to add these block headers at a later time.
On Sun, Jul 27, 2008 at 7:30 AM, Richard Sharpe
<realrichardsharpe at gmail.com> wrote:
> OK, so I tar'd up some 20GB of data to my remote virtual tape via
> iSCSI etc, but the virtual tape file at the remote end only contained
> 10kB, the last 10kB of the tar file.
> This seems to be because of deficiencies in the ssc.c etc code.
> Since it uses the standard bs_thread_submit_cmd it relies on bs_rdwr.c
> to do the writing and reading ... which expects an offset, but the ssc
> code always supplies this as zero (since it is never sent).
> Since we are dealing with a sequential device, which might, however,
> be rewound or be positioned to weird block offsets, or be asked to
> position to the next tape mark, this functionality needs to be in
> I suggest that when the LU us created we need to allocate some private
> space where we will keep this information, and then, before we submit
> the command, do the correct things to it.
> I am going to start doing this because I need this stuff to work correctly ...
> Stgt-devel mailing list
> Stgt-devel at lists.berlios.de
More information about the stgt