uweseimet
commented
2 years ago @Pacjunk Can you please point out which function is calling itself? I don't think this happens anywhere. Of course, code for similar functionailty like READ(6/10/16) is now reused.
In order to add READ/WRITE LONG you might try to copy Read10 and Write10 (see disk.cpp) first, then modify the copied code as needed (maybe no modification is needed at all in your case), and then add the respective AddCommand() calls to the Disk class constructor. In sasidev_ctrl.cpp you have to add eCmdWriteLong10 to the switch in the FlushUnit() method.
Note that the difference between READ/WRITE and READ/WRITE LONG is NOT that the length is in bytes. This is from SBC-3:
The READ LONG (10) command (see table 74) requests that the device server transfer data from a single
logical block or physical block to the Data-In Buffer. The data transferred during the READ LONG (10)
command is vendor specific, but shall include the following items recorded on the medium:
a)if a logical block is being transferred, then:
A) user data or transformed user data for the logical block;
B) protection information or transformed protection information, if any, for the logical block; and
C) any additional information (e.g., ECC bytes) for all the physical blocks in the logical block;
or
b)if a physical block is being transferred, then:
A) user data or transformed user data for all the logical blocks in the physical block;
B) protection information or transformed protection information, if any, for all the logical blocks in the
physical block; and
C) any additional information (e.g., ECC bytes).
If the additional information contain an ECC, then any other additional bytes that are correctable by ECC
should be included (e.g., a data synchronization mark within the area covered by ECC). It is not required for
the ECC bytes to be at the end of the logical block data. The ECC bytes should be in the same order as they
are on the medium.
If a cache contains a more recent version of the specified logical block or physical block, then the device
server shall write the logical block or physical block to the medium before reading it. The values in the
Read-Write Error Recovery mode page (see 6.5.8) do not apply to this command. The device server may
perform retries while processing this command.
This command uses the SERVICE ACTION IN (16) CDB format (see A.2).
NOTE 14 - Migration from the READ LONG (10) command to the READ LONG (16) command is
recommended for all implementations.
The OPERATION CODE field is defined in SPC-4 and shall be set to the value shown in table 74 for the READ
LONG (10) command.
If there is more than one logical block per physical block (i.e., the LOGICAL BLOCKS PER PHYSICAL BLOCK
EXPONENT field in the READ CAPACITY (16) parameter data (see 5.16.2) is set to a non-zero value), then:
a) the device server shall support the physical block (PBLOCK) bit;
b) a PBLOCK bit set to one specifies that the device server shall return the entire physical block containing
the specified logical block; and
c) a PBLOCK bit set to zero specifies that the device server shall return bytes representing only the
specified logical block.
If there are one or more physical blocks per logical block (i.e., the LOGICAL BLOCKS PER PHYSICAL BLOCK
EXPONENT field in the READ CAPACITY (16) parameter data (see 5.16.2) is set to zero), and the PBLOCK bit is
set to one, then the device server shall terminate the command with CHECK CONDITION status with the
sense key set to ILLEGAL REQUEST and the additional sense code set to INVALID FIELD IN CDB.
A correct (CORRCT) bit set to zero specifies that a logical block be read without any correction made by the
device server. A CORRCT bit set to zero should result in the device server completing the command with
GOOD status unless data is not transferred for some reason other than that the data is non-correctable. In this
case the device server shall complete or terminate the command with the appropriate status and sense data.
A CORRCT bit set to one specifies that the data be corrected by ECC before being transferred to the Data-In
Buffer.
The LOGICAL BLOCK ADDRESS field specifies an LBA (see 4.5). If the specified LBA exceeds the capacity of the
medium (see 4.5), then the device server shall terminate the command with CHECK CONDITION status with
the sense key set to ILLEGAL REQUEST and the additional sense code set to LOGICAL BLOCK ADDRESS
OUT OF RANGE.
The BYTE TRANSFER LENGTH field specifies the number of bytes of data that shall be read from the specified
logical block or physical block and transferred to the Data-In Buffer. If the BYTE TRANSFER LENGTH field is not
set to zero and does not match the available data length, then the device server shall terminate the command
with CHECK CONDITION status with the sense key set to ILLEGAL REQUEST and the additional sense code
set to INVALID FIELD IN CDB. In the sense data (see 4.18 and SPC-4), the VALID bit shall be set to one and
the ILI bit shall each be set to one, and the INFORMATION field shall be set to the difference (i.e., residue) of the
requested byte transfer length minus the actual available data length in bytes. Negative values shall be
indicated by two's complement notation.
A BYTE TRANSFER LENGTH field set to zero specifies that no bytes shall be read. This condition shall not be
considered an error.
The CONTROL byte is defined in SAM-5.
By the way, READ LONG (but not WRITE LONG) is legacy and not supported anymore since SBC-4 from 2020.
Pacjunk
rdmark
Info
Describe the issue
The OpenVMS SCSI driver "tests" the capability of the drive for the volume shadowing feature by sending hundreds of READ LONG(10) commands when mounting a volume. It seems to ignore the unsupported error message that this creates and keeps trying.
Is it possible to implement these commands - 1. To stop the above issue and 2. It might be fun to support volume shadowing.
I had a look at the code as I thought it might be easy since the CDB layout seems to be the same as the READ(10) and WRITE(10) commands, the only difference being that the length is in bytes, rather than blocks. I'm not a very good C++ programmer, so I find it confusing the way the code is spread amongst several files, there are multiple definitions of functions (which one to use?) and even functions calling themselves. I could start hacking it, but I fear the code will soon become a mess.
Can someone who is confident with the code have a look at the viability of this?
Thanks,