On Jan 27, 2018, at 3:09 AM, Stephan Beal <[email protected]> wrote: > > Simply reading that file for insertion into the db requires 1x its size.
Obviously this *could* be changed, so that BLOBs stream into and out of the SQLite DB in chunks. That gets us back to motivation: why spend the effort on a use case that only breaks down when working with files with a minimum size approaching the size of available VM? If you want that to change, Martin, you’ll have to justify your use case. Why do you want to do this, and why do you think Fossil is a sensible platform for supporting that use case? There are cases where you want a DVCS and cases where you want a distributed filesystem. This seems like one of those latter cases. > Your system is very likely failing on that first allocation of 17GiB. Yes, which means this is not a “bug.” It just means you’ll need something like 64 GB of VM and a 64-bit OS to work with this particular Fossil repository. If that means you force your OS to do heavy paging while doing so, you can expect Fossil to be much slower than copying similarly-sized files around on a filesystem. I can’t do anything with your test case right now, Martin. The torrent tracker isn’t responding at all, and the file download is currently proceeding at about 1.5 Mbit/sec, so it’s going to take hours to get here. I may try it from another location before Monday, but don’t hold your breath waiting on me. _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
