Please allow changing the location of the mainnet folder

[SlugFiller]

Describe the bug I initially looked at this simply as a missing feature, until I realized that, at the current rate, before the end of this year, this will become a breaking bug that will not allow me to run a Chia client at all.

The mainnet folder is quickly growing by the gigabyte, and yet, it defaults to a drive that has only a few free gigabytes left, with no way to move it. Once that drive is inevitably filled, I would no longer be able to run the program.

At any rate, I prefer to report it now before it turns into a crash-inducing bug.

To Reproduce Steps to reproduce the behavior:

1. Run Chia
2. Wait for the full node to sync
3. Look at remaining free space on system drive

Expected behavior Free disk space left for critical system temp files and paging file

Desktop (please complete the following information):

• OS: Windows
• OS Version/Flavor: 10
• CPU: Intel i7

Additional context An alternative is to have lightweight simple-verification wallets that don't require the full db. This would at least allow owning Chia, but would prevent farming. At any rate, having a small SSD as a system drive is far from a rare setup, and this severely limit the network's growth and adoption.

[gromran]

simple workaround: symlinks

[SlugFiller]

@gromran As specified in the report, the OS is Windows. There are no symlinks. Believe me, it's the first thing I would have done. What I could potentially do is run it in a docker container or colinux, but that's a bit much.

[gromran]

the OS is Windows. There are no symlinks.

You are wrong, you can map one folder in another, even with Windows https://www.howtogeek.com/howto/16226/complete-guide-to-symbolic-links-symlinks-on-windows-or-linux/

[mbaric1]

@SlugFiller Look at the Quick Start Guide - Install section. You can override $CHIA_ROOT env variable with the path you want to store Chia configuration in. Also don't forget to migrate existing configuration.

[arielylim]

Or wouldn’t it be easier to change the path of the databases in your config.yaml to another area?

full node:
  database_path: change_this_somewhere_else

wallet: 
  database_path: same_here

Haven’t tried this though.

[markusmazurczak]

@SlugFiller Look at the Quick Start Guide - Install section. You can override $CHIA_ROOT env variable with the path you want to store Chia configuration in. Also don't forget to migrate existing configuration.

Did not tested it, but this should do the trick. Stop all chia processes. Move mainnet folder to your desired location. Update/Set $CHIA_ROOT. Run init. Run your desired processes

[SlugFiller]

Okay, the $CHIA_ROOT solution works. Seems to require setting directly to the mainnet folder, and not the .chia folder. It's a bit user unfriendly, but working, So I suppose this can be closed.

[keliew]

Has anyone checked if this affects farming performance when changing the db to a remote location?

[gromran]

Has anyone checked if this affects farming performance when changing the db to a remote location?

There are a lot of small(!) read / write accesses to the sqlite db (really a lot!) So when embedding is slow (slow NAS e.g.)... On a local system/symlink this shouldn't be a problem

[876873549]

I still don't know how to do it, $Chia_ ROOT

[SlugFiller]

@876873549 In the start menu, type environ to find "Edit the system environment variables". In the window that opens, click on "Environment Variables...". Click on the lower "New...". In "Variable name" type "CHIA_ROOT". In "Variable value" type the path where you want the mainnet folder (e.g. "F:\MyChia\mainnet"). Click "Ok" twice.

After that, make sure Chia is completely closed, and move the mainnet folder from ~/.chia/mainnet to the location you chose, then start up Chia.

[876873549]

@SlugFiller okay, thank you

[emlowe]

Closing issue - CHIA_ROOT is currently the solution to this.

[scscgit]

CHIA_ROOT env most certainly isn't acceptable solution for most end users, as these kinds of obvious issues that everyone inevitably faces should be properly communicated and configurable via UI rather than asking users to come on GitHub and read the issue comments. Also this didn't address OP's Expected behavior of Free disk space left for critical system temp files and paging file, as it this sudden downtime of our machines is definitely a problem even if a person creating this issue can live with that being unresolved. This behavior should be up to our choice; some of us would prefer for the farming to stop altogether before it causes a system crash. Moreover, the preferable solution would be if we could also split the data to multiple drives rather than forcing them to one location. Specifically, you can notice how all plotting drives have "some leftover space", which would be a perfect place to put the ever-growing blockchain. Soon all casual plotters will have to dedicate majority of their space to the blockchain, which will mostly impact those with smaller drives (but we all know that your "Anyone, including individuals on their home computers, should be able to participate" was just a clever advertisement to gain moral advantage even though you don't really plan to follow up on making this reasonable for small users, judging from the current insane UX of the GUI). Also, if we have to resort to moving blockchain to non-primary drives, it's very likely that it'll be placed on less stable (used/old) HDDs, in which case both the configuration/temp files and the (db/wallet) blockchains will share the same risk of data corruption. If there were instead an automated process in place to only move automatically recoverable files to the more volatile drives, losing parts of a blockchain wouldn't have to cause a total downtime of farming, as the missing files could be seamlessly generated while re-using any existing ones before continuing; along with a possible removal of duplicates if space starts to run out. Regarding the sync issues, there was one great idea about making a periodic job to scatter db across all farming disks. And let's not forget that the process of loading the blockchain could be way faster if HDDs could be used in parallel. The most optimal solution would include pooling network HDDs between computers... Last but not least, if we put the blockchain on farming drives, it becomes very impractical to move them around between computers, and this also includes the common scenarios when HDDs fail, for example if a motherboard has faulty USB ports, or if system fails to recognize the drive until a next restart (and I envy you if you live in a bubble where this isn't a common occurrence).

And of course, as always, Chia client has additional issues after setting the CHIA_ROOT, as it keeps loading indefinitely (while causing HDD load based on resmon), and even though it was possible after 10 hours to somehow click around the GUI and get it moving, it still got stuck on "Syncing..." without a progress, and it's back to the original issue after a restart. It seems like removing other files including config had additional effect, but it's still impossible to debug...

EDIT: For anyone with a similar issue like "Syncing...", check your chia logs, they told me that the DB has been corrupted. (...which is interesting because I just moved a copy that previously worked, and I had no other issues with that HDD, so Chia's DB implementation seems to have a tendency to corrupt the blockchain without any recovery measures. I guess it'll be fun to watch the suffering of users once blockchain grows to 1TB. The same issue has actually happened to me several additional times when copying it between computers, and I had to throw away several copies. If your time has any value, setting up Chia really isn't worth it unless you've got 100s of TBs and a few months to spare in addition to the most pessimistic estimations & plotting issues). It got fixed after deleting and re-downloading it, which takes an insane amount of time if you don't have any backup.