-1



I am developing a low level SATA driver for an FPGA based embedded system. The driver is running fine.

When I read sectors from the disk using dd command, I can see that the SCSI read(10) command (opcode 0x28) is recived by my low level driver, which is I think correct. But, when I write sectors to the disk using dd command, the SCSI driver sends first read(10) command (opcode 0x28) for several times and then few write(10) commands (opcode 0x2A).

Can someone explain me, that why does SCSI driver send read() command during the write operation?


Edited: During a file write operation I can see that the driver first reads (DMA mode) from LBA 0 upto some 8 sectors. Then it writes (DMA) sg blocks and then it reads (PIO) disk specific information. After that it takes some random LBAs and performs several reads(DMA) finally it stops by reading device specific data read(PIO). This is a sequence for dd'ing 1KB file. The disk has no partition table and no file system (verified from fdisk utility ). Is it a normal behaviour of driver? If yes then is it not decreasing the speed of operation? As overall file reading is faster than writing due to extra reads in write operation.

Thank you

Ganesh Kalbhor
  • 53
  • 8
  • Does it do that sequence every time you run dd? Linux will scan for partition tables when a new device comes online, but it shouldn't be repeating that dance if you've left the device connected and run dd a second time. – Mike Andrews Dec 22 '16 at 16:26
  • Yes, for every "dd if=somefile.txt of=dev/sda bs=1KB count=1" the same sequence of commands is executed let it be first time or any number of times. Device is always connected to the host. Do we have to alter something in SCSI driver? I did not change anything in SCSI driver I just initialized a SCSI SHT structure and related functions in my low level driver. – Ganesh Kalbhor Dec 23 '16 at 09:04

1 Answers1

1

It's hard to say concretely without knowing more about your system. Two possibilities come to mind:

  1. Linux is looking for partition tables. This is likely the case if the reads are to LBA 0 and the first few logical blocks, or if the reads are to the very end of the device, where there is a secondary GPT header.

  2. You're dd'ing a file on a filesystem, and the filesystem is reading in uncached metadata.

Mike Andrews
  • 3,045
  • 18
  • 28
  • Hi, thanks for the reply. I think the first reason you mentioned is partially correct. I have edited the question and added more information on the behaviour of the driver. – Ganesh Kalbhor Dec 22 '16 at 11:17