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

From: rsbecker@nexbridge.com <rsbecker@nexbridge.com>
Date: Apr 8, 2026, 20:08 UTC
Message-ID: <014e01dcc793$8a9bab90$9fd302b0$@nexbridge.com>
In-Reply-To: <xmqq4illz5g9.fsf@gitster.g>

On April 8, 2026 2:13 PM, Junio C Hamano wrote:

Show 18 quoted lines

>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?