uweseimet
commented
7 months ago @pacjunk In case you are still interested in support for READ/WRITE LONG I would appreciate your feedback. The develop branch of SCSI2Pi provides improved READ/WRITE LONG support. See https://www.scsi2pi.net for details on the project.
I have already successfully tested the new functionality, which currently supports READ/WRITE LONG transfer sizes up to the actual sector size of a drive. As far as I can tell from https://github.com/PiSCSI/piscsi/issues/479 in your case more than the actual sector size needs to be transferred. This is something I might support, but this would have to be tested with a platform that actually uses these commands. My own testing is based on sending READ/WRITE LONG commands to s2p and monitoring the results.
The excess bytes are supposed to be special data, e.g. checksums, and in order to support these data, which do not actually exist in an image file, I see these options:
- Use a sector size of more than 512 bytes, e.g. 516 bytes. This would probably work if no regular READ/WRITE calls are used, but only READ/WRITE LONG. In this case the sector size essentially loses its meaning, and a sector is just a blob of data. SCSI2Pi supports any size that is a multiple of 4 with the latest develop branch.
- Use a regular sector size but return dummy data for anything beyond the regular sector.
- Do the same that BlueSCSI does, whatever that is, because you reported that BlueSCSI works for your setup. (BlueSCSI v2 does not support READ/WRITE LONG, and I wonder whether v1 does.)
READ/WRITE LONG support requires one of the caching modes "write-through", "linux" or "linux-optimized" for the respective drive.
The caching modes "linux" and "write-through" do not rely on transfer sizes based on sector sizes. This means that for devices where caching is based on the linux filesystem cache it should be possible now to implement READ/WRITE LONG for any transfer size smaller than the sector size.