>>>>> "Vladislav" == Vladislav Bolkhovitin <vst@xxxxxxxx> writes: Vladislav> Linux block layer is purely artificial creature slowly Vladislav> reinventing wheel creating more problems, than solving. On the contrary. I do think we solve a whole bunch of problems. Vladislav> It enforces approach, where often "impossible" means Vladislav> "impossible in this interface". I agree we have limitations. I do not agree that all limitations are bad. Sometimes it's OK to say no. Vladislav> For instance, how about copy offload? How about atomic Vladislav> writes? I'm actively working on copy offload. Nobody appears to be interested in atomic writes. Otherwise I'd work on those as well. Vladislav> Why was it needed to create special blk integrity interface Vladislav> with the only end user - SCSI? Simple. Because we did not want to interleave data and PI 512+8+512+8 neither in memory, nor at DMA time. Furthermore, the ATA EPP proposal was still on the table so I also needed to support ATA. And finally, NVM Express uses the blk_integrity interface as well. Vladislav> The block layer keeps repeating SCSI. So, maybe, after all, Vladislav> it's better to acknowledge that direct usage of SCSI without Vladislav> any intermediate layers and translations is more productive? Vladislav> And for those minors not using SCSI internally, translate Vladislav> from SCSI to their internal commands? Creating and filling Vladislav> CDB fields for most cases isn't anyhow harder, than creating Vladislav> and feeling bio fields. This is quite possibly the worst idea I have heard all week. As it stands it's a headache for the disk ULD driver to figure out which of the bazillion READ/WRITE variants to send to a SCSI/ATA device. What makes you think that an application or filesystem would be better equipped to make that call? See also: WRITE SAME w/ zeroes vs. WRITE SAME w/ UNMAP vs. UNMAP See also: EXTENDED COPY vs. the PROXY command set See also: USB-ATA bridge chips You make it sound like all the block layer does is filling out CDBs. Which it doesn't in fact have anything to do with at all. When you are talking about CDBs we're down in the SBC/SSC territory. Which is such a tiny bit of what's going on. We have transports, we have SAM, we have HBA controller DMA constraints, system DMA constraints, buffer bouncing, etc. There's a ton of stuff that needs to happen before the CDB and the data physically reach the storage. You seem to be advocating that everything up to the point where the device receives the command is in the way. Well, by all means. Why limit ourselves to the confines of SCSI? Why not get rid of POSIX read()/write(), page cache, filesystems and let applications speak ST-506 directly? I know we're doing different things. My job is to make a general purpose operating system with interfaces that make sense to normal applications. That does not preclude special cases where it may make sense to poke at the device directly. For testing purposes, for instance. But I consider it a failure when we start having applications that know about hardware intricacies, cylinders/heads/sectors, etc. That road leads straight to the 1980s... -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
