Repo indexer - Max file size

[ghost]

gitea v1.4.0-rc1

I am trying to change the repo indexer max file size. I setted it to 5242880, but the repo file size is fixed to:

Seems that the setting doesn't be load correctly:

I also tried to change the setting, and erased the repo folder, but anyway the size seems to be fixed.

Regards

[lafriks]

MAX_FILE_SIZE is not for index size but for up to how big files to index

[ghost]

Thank you for your fast answer @lafriks . Then, what about the fixed "store" file size? I am trying to indexing a big project, and some of the files was indexed, but seems to be that not everyone, and I supposed that it depends maybe from the "file size"

[lafriks]

how big is file that was not indexed?

[ghost]

Only 9KB, and is a Java file

[lafriks]

Do you see any errors in log file? and why do you think it was not indexed?

[ghost]

No errors in log file. I am sure that the file was not indexed because I am trying to look also for other strings inside this file, but no results appear.

[ghost]

I just replicated the problem. If I create a new repository with just this file and just this repo, then the file is indexed correctly. I think that the problem is the max "store" file size

[lafriks]

I don't think there is maximal size for store file

[ghost]

You can try to replicate the problem by cloning the repo: https://github.com/Xilinx/u-boot-xlnx
and search for string: "dm_test_adc_bind" (that is present in file "test/dm/adc.c"). Even in this case, the store file goes to a size of 1.048.576 KB and stop working (stop to grow up and to index files)

[lafriks]

@ethantkoenig can you check this?

[ghost]

@ethantkoenig @lafriks Thank you. I also want to add an additional information: with the same repository occured also an access violation during repo indexing: Exception

[ethantkoenig]

In my experience, bleve does not do well once index files approach/exceed 1 GB (although it may be different for other machines and OS's). I do recall seeing similar behavior at some point (where an index file remained the exact same size as more content was added to it), but wasn't able to figure out what was going on.

I have found that using sharded indices (not natively supported by bleve) allows bleve to scale more gracefully. Perhaps this is something to consider using in gitea.

[ghost]

Thank you for your answer @ethantkoenig . Are there any workaround to avoid this behavior?

[ghost]

I also want to add some external links to boltdb:
boltdb/bolt#266
boltdb/bolt#308
https://github.com/boltdb/bolt/blob/master/db.go (check comments at row 17, and starting from line 305)
Are those useful?

[ghost]

@ethantkoenig an additional information: your lasts commit on master, changed the store max size to 524.288 KB, instead of, for "v1.4.0-rc1" the size is fixed to 1.048.576 KB

[ghost]

@ethantkoenig @lafriks After hours of reverse engineering I think that I found the problem about max store sizing on gitea v1.4.0-rc1. On monday I will test mine tricky-hack on production gitea, and I will let you know about it here

[lafriks]

@giudon that's great to hear

[ghost]

@ethantkoenig @lafriks Now I can confirm my analisys: there is a problem in boltdb. In particular it happens in such particular cases, when is needed to remap the store file after 1GB. The problem is still present in the master version, because I seen that on gitea we are using this db.go version https://github.com/boltdb/bolt/blob/ccd680d8c1a0179ac3d68f692b01e1a1589cbfc7/db.go (this commit was done by @lunny , and after this there is only one commit more, that doesn't change the remap logic on db.go).
The following are the technical details (before start, I want to say that my OS pageSize, on a Windows 64 bit machine is equal to 4.096 bytes):
When boltdb needs to allocate new "junk" to store file, this method is called:

as you can see, when is needed to increase the store file is called the method "mmap" with a minimum size reallocation parameter. Inside "mmap" is called the method "mmapSize", that calculate the new store file size based on the minimum one passed as parameter:

as you can see from my red comments, there are 2 different calculation methods inside "mmapSize". The first one calculate the new store size following this rule, based on the minimum size parameter:
2^15 = 32.768 bytes
2^16 = 65.536 bytes
2^17 = 131.072 bytes
2^18 = 262.144 bytes
2^19 = 524.288 bytes
2^20 = 1.048.576 bytes
2^21 = 2.097.152 bytes
2^22 = 4.194.304 bytes
2^23 = 8.388.608 bytes
2^24 = 16.777.216 bytes
2^25 = 33.554.432 bytes
2^26 = 67.108.864 bytes
2^27 = 134.217.728 bytes
2^28 = 268.435.456 bytes
2^29 = 536.870.912 bytes
2^30 = 1.073.741.824 bytes
and this method works well.
The problems starts when the second calculation method take control over remap size, because the minimum size that is passed as parameter when 1GB is reached was "1.073.741.824", and not as I was expecting a value greater than "1.073.741.824".
So, when 1GB is reached, simply the mmapSize return the same minimum size passed as parameter (1.073.741.824), because following codes:

are not reached.

My little tricky-hack to let it works, is to comment the following red lines inside "mmapSize" method:

and so, when 1GB is reached, the new allocation size will be increased everytime by os.Getpagesize().
Now repo indexing work fine:

What do you think about it guys?

[lafriks]

@giudon great bug hunting :) can you report this upstream to boltdb?

[ghost]

@lafriks did it

[guillep2k]

Bolt have become archived/unmaintained. Proposed alternative seems to be https://github.com/etcd-io/bbolt. Perhaps it's worth taking a look at it?

[lunny]

It's outdated and now the latest version depends on go.etcd.io/bbolt indirectly.