$ cat /proc/scsi/sg/debug dev_max(currently)=7 max_active_device=1 (origin 1) scsi_dma_free_sectors=416 sg_pool_secs_aval=320 def_reserved_size=32768 >>> device=sg0 scsi0 chan=0 id=0 lun=0 em=0 sg_tablesize=255 excl=0 FD(1): timeout=60000ms bufflen=65536 (res)sgat=2 low_dma=0 cmd_q=1 f_packid=1 k_orphan=0 closed=0 fin: id=3949312 blen=65536 dur=10ms sgat=2 op=0x28 act: id=3949440 blen=65536 t_o/elap=60000/10ms sgat=2 op=0x28 rb>> act: id=3949568 blen=65536 t_o/elap=60000/10ms sgat=2 op=0x28 act: id=3949696 blen=65536 t_o/elap=60000/0ms sgat=2 op=0x28 |
Each line indented with 5 spaces represents a SCSI command. The state of the command is either:
If sg has lots of activity then the "debug" output may span many lines and in some cases appear to be corrupted. This occurs because procfs requests fixed buffer sizes of information and, if there is more data to output, returns later to get the remainder. The problem with this strategy is that sg's internal state may have changed. Rather than double buffering, the sg driver just continues from the same offset. While procfs is very useful, ioctl()s (such as SG_GET_REQUEST_TABLE) still have their place.