Is there a file size limitation Calc ods file

Last Nov after accessing an ods file I was hit with the error message “The file is … corrupt and therefore cannot be opened … can try to repair the file … this document.” I rebuilt the profile dealt with the “rabbit hole” that the file corruption error took me. I did not get back to any normalcy until I removed a sheet from a previous backup of the problem file. It was reduced to 1.5 gig from 2.0 gig.

Things went rocking along until the same corrupt issue cropped up again as I reached a file size of 2.0 gig.
Knowing I was nearing this threshold I had been backing up this ods file daily to another internal drive with the same OS. I moved this last backup to my main working drive and overwrote the reported corrupt file. No corrupt file message appeared when accessed. Great, but how can I continue any further work if I cannot get past what seems to be an apparent 2 gig limitation?

Given: LibreOffice 00(Build:1)
16G System memory processor AMD Ryzen 5 2600 Six-Core Processor
ubuntu 20.04 5.4.0-65-generic #73-Ubuntu

Filesystem     1K-blocks      Used            Available     Use% Mounted on
/dev/sda2      481389624   128030008 328836636  29%     /

[Edit Opaque] Changed filesystem info to pre-formatted text

Which filesystem type are you using on /dev/sda2 - is it ext4 or something else? What does ulimit -a tell about file size?

It is ext4 with “unlimited” response to ulimit command
Additional note: I overwrote the corrupt file with the backed up file again, deleted the contents of one cell, tried to save but it took down the rabbit hole again after attempting recovery.

And you save as .ods or some uncompressed xml file format?

There is technical limitation that standard imposes on the file size per se. ZIP APPNOTE Version 6.2.0 allows using 64-bit file format, making it unlimited for practical purposes. However, large files are not used widely, and thus not tested in practice, which allows to have multiple corner-case bugs lurking around unnoticed, e.g. because of wrong use of 32-bit integers somewhere.

I worked around the problem by separating a sheet with hyperlink objects to the main body as a file.
Strangely enough when I total the main sheet (850m) and the separated file (only 1m) it is less than half of the suspected 2Gig limit.

I had to split off a sheet containing hyperlinks to the main body.
Strangely enough the total size(1M and 810M)of the 2 separated files is less than 1G, half of the suspect 2 gig limitation.