RE: Git 2.54.0-rc1, subtests of t5310, t5326, t5327

[<rsbecker@nexbridge.com>]

On April 8, 2026 2:13 PM, Junio C Hamano wrote:
>Jeff King <peff@peff.net> writes:
>
>> On Wed, Apr 08, 2026 at 12:25:47PM -0400, rsbecker@nexbridge.com wrote:
>>
>>> This is also impacting t5608 and t7700. Anywhere where writev() is
>>> used, seemingly. We went through MAX_IO_SIZE issues years ago,
>>> instead of using ssize_t as a basis of how big communication is. I
>>> think
>>> writev() is not valid. It worked on Lunix, but had issues elsewhere.
>>> This broke the compat layer.
>>
>> I wondered briefly if the problem could be that we're violating
>> MAX_IO_SIZE here, as our use of writev() does not respect it at all.
>> But the only spot that uses it is feeding pkt-line packets, which max
>> out at 64k. So unless your MAX_IO_SIZE is smaller than that, I doubt
>> that is the problem.
>
>Good point.  The original did not use write(2) directly but used
write_or_die(), that
>is write_in_full(), that loops over xwrite(), so it would have worked even
with a lot
>lower MAX_IO_SIZE limit.
>
>According to man7.org, writev() is allowed to transfer fewer bytes than
requested,
>so our use of writev() may have to be a bit more careful, though.

On my box, I have the following note:

Specifying  the sum of the iov_len values in the iov array greater than
the OSS I/O size limit for that open causes the  writev()  function  to
return  -1  and  set errno to [EINVAL].

This can be either 52K (SSIZE_MAX) or 868K depending on the build settings.
We are currently stuck with 32-bit builds, with large file support, so
really no
limit on the file sizes, but due to dependencies that are stuck at 32-bit
until I
convince the powers that be to fix those. Please, can we be compliant with
MAX_IO_SIZE?