Maximum transaction size/splitting up large transactions?

[Zach Brown]

On Wed, Apr 02, 2025 at 05:37:55PM +0200, Valerie Aurora wrote:

> That makes sense. I think my question is more "what do I do when a
> user requests a single gigantic IO?" Right now, if you ask ngnfs to
> write 1GB at once, it will try to put it all in one transaction. I
> assume the transaction system would like something a little bit
> smaller to work with!

It sure would!  Never mind oom from pinning entire syscall args, holding
cached write blocks for that long seems like a great way to hit
contention.

> The easy answer is to truncate the length of all IO requests to
> something "reasonable" for the transaction system and have the user do
> the usual loop until all bytes are written. 

"truncate" feels loaded to me here :).  But yes, this is what we'll do.
Choose a smaller transaction size and iterate 'till the operation is
done.  A naive first pass would be playing a little fast and loose with
POSIX write atomicity, but we can layer on that complexity as needed.
(It comes down to serializing on write holds of a file-granular block so
that truncates/writes behave as expected across the network).

> But what is reasonable? 5MB? I have no idea.

5MB for an individual client transaction feels big.  It seems like it'd
take a smaller number of blocks to get to the diminishing returns of
client CPU cost / block.  And, as mentioned, we have the powerful
motivation to keep transactions small so that they're less likely to hit
conflicts with other transactions.

I'll probably have something specific to say when I go review the actual
code, which I'll now do!

- z