Hi Konstantin,
There might be indeed a reason, it could be that some drivers expect blocking to be done by the userspace. The drivers could have some restrictions on transfer sizes and atomicity of transfer, which would be broken by the unconditional merge. I cannot give you an example of such driver, known block-aware drivers like sa(4) only require the bio size to be multiple of the basic block size.
I'm surprised to learn that the generic access layer splits IO requests just because some block drivers cannot handle it. I'd expect that this sort of limitation would be communicated by the drivers in the form of device flag SI_NOMERGE.
OTOH, I see no issue with adding a SI_PHYSIOMERGE flag and doing the merges for the driver in physio(), when unmapped request has consequtive iov elements ending and starting at the page boundary.
I'd say it should be the other way around, physio would always strive to append/merge iov elements but wouldn't in case the device does not support it. Moreover, some modern devices does not even require the page boundary alignment you mentioned. These devices can execute IO to/from any arbitrary scatter list of buffers. _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-geom To unsubscribe, send any mail to "[email protected]"
