Dave, > But if the application is limited to atomic_write_unit_max sized > IOs, and that is always less than or equal to the size of the atomic > write boundary, why does the block layer even need to care about > this whacky quirk of the SCSI protocol implementation? Dealing with boundaries is mainly an NVMe issue. NVMe boundaries are fixed in LBA space. SCSI boundaries are per-I/O. > In what cases does hardware that supports atomic_write_max_bytes > > atomic_write_unit_max actually be useful? The common case is a database using 16K blocks and wanting to do 1M writes for performance reasons. > There are many well known IO optimisation techniques that do not > require the kernel to infer or assume the format of the data in the > user buffers as this current API does. May the API simple and hard > to get wrong first, then optimise from there.... We discussed whether it made sense to have an explicit interface to set an "application" block size when creating a file. I am not against it, but our experience is that it doesn't buy you anything over what the careful alignment of powers-of-two provides. As long as everything is properly aligned, there is no need for the kernel to infer or assume anything. It's the application's business what it is doing inside the file. -- Martin K. Petersen Oracle Linux Engineering
