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 <[EMAIL PROTECTED]> 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 > [email protected] > https://lists.berlios.de/mailman/listinfo/stgt-devel > _______________________________________________ Stgt-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/stgt-devel
