>>>>> "Chris" == Chris Murphy <lists@xxxxxxxxxxxxxxxxx> writes: Chris, Chris> The SCSI layer is clearly combining the bs=512 count=8 into a Chris> single write command. This is inhibited with oflag=direct. It's not really the SCSI layer that does any of this but the VM and/or the I/O scheduler (depending on how things were submitted). Chris> I also found intermittent issuance of READ_10 to the drive, Chris> before WRITE_10, but wasn't able to figure out why it's Chris> intermittant. It's either the page cache doing readahead or you doing partial writes to uncached pages. You can flush the page cache like this: echo 3 > /proc/sys/vm/drop_caches >> You do know that drives are physically incapable of writing partial >> sectors? It has to be emulated, either in drive firmware or OS >> driver stack. What you've written suggests you've missed that basic >> reality. The rest is operator error. Roman and Wolfgang were too >> polite when pointing out the need for bs=4096 -- it isn't 'should', >> it is 'must'. Chris> That's true for oflag=direct, it's not true without it. Correct. In general, a buffered write() call in dd or any other userland app does not have a 1:1 mapping with a SCSI WRITE command at the bottom of the stack. The pages in question will simply be marked dirty and eventually flushed to disk. You can force a more block-centric behavior by using synchronous/direct I/O. Chris> Also included for interest is the result of issue an hdparm write Chris> command. It works without a size specification, so I don't Chris> actually know what happens on the drive itself, plus the command Chris> that gets issued to the drive isn't "WRITE_10" but "ATA_16". That's because the ATA command gets encapsulated in a SCSI command so it can pass through the SCSI layer. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
