[Stgt-devel] Further problems with the SSC code ...

[ronnie sahlberg]

Hi,

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.


ronnie sahlberg


On Sun, Jul 27, 2008 at 7:30 AM, Richard Sharpe
<realrichardsharpe at gmail.com> wrote:
> Hi,
>
> 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
> ssc.c.
>
> 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
> https://lists.berlios.de/mailman/listinfo/stgt-devel
>