Setting a 2nd temp folder and its expected behavior

From what I gather setting a 2nd temp will balance some of the writes required for temp 1 into temp 2 during the early phases of the plot (temp 2 is always in use). I recall reading somewhere that a user used it as a spillover reserve because his main temp SSD was an odd size so sometimes it would come up short and crash without it. This sounds more like temp 2 behaves retroactively and is only used when it is needed.

What are peoples experiences in trying out a 2nd temp? Do you scale it smaller than the 1st temp as that guy did?

My understanding is different.

Phases 1 + 2 always happen in the main temp dir. If you have tmp2 configured, it will do phase 3 and 4 there. The plotting log output has some good hints. Here’s an example from Phase 3 starting up:

Starting phase 3/4: Compression from tmp files into "/chia/final/plot-k32-2021-05-13-15-11-3199b469414b366a43756d7b41abc6f8db9bac5f9767dffb32eebdd07f747db2.plot.2.tmp" ... Thu May 13 19:48:59 2021

On that plotter, I have the -2 directory set to the same directory as the final plots (ie: /chia/final).

4 Likes

That’s exactly right. The -2 flag is used in phase 3 as the destination of the compression of the tables generated in phase 1 and 2. In other words, it’s where the final plot gets built up.

If -2 is the same folder as -d, then there is no “move” operation at the end of phase 4. It’s only a rename.

You might want to make -2 = -d if you don’t have enough space in -t, but most people will be better off making -t = -2 on an SSD and having -d be on a HDD. Or make all three the same and perform a manual move later.

Everyone’s system is a bit different, so it can help to experiment and see what kind of times you are achieving with the different configurations.

4 Likes

I see, this clears things up. Setting -2 to -d would save the copy steps in the final merge. This performs less writes on the SSD if the 3rd and 4th phases are set to go directly to the hdd (or destination drive). What percentage of the temp space is split off or offset rather to temp 2? I suppose it must be just under the total size of the plot. I’ll definitely will be doing some experimenting when my hardware arrives this weekend. Thanks all for your feedback. :+1:t2:

2 Likes

True.

Also true, but most of the writes occur during Phase 1.

It is the final plot itself, so ~102 GiB for a K32. When you begin Phase 1, a file of size 0 called [name].tmp gets created in the -2 folder. The size remains 0 until the beginning of Phase 3, when the compression of tables from -t get added to the file in the form of checkpoint tables. When these checkpoint tables are all written, [name].tmp, is the final plot other than a move and a name change, which happen in Phase 4.

1 Like

Sorry I said that slightly wrong. The compression happens in Phase 3 and the checkpoint tables get written at the beginning of Phase 4, before the move/rename.

2 Likes

Even in Phase 3, massive amounts of read/write is going in temp1 as compared to temp2.
Below is sar -p -d output with 20 plots in phase 3 and non in phase1 or 2.

20:35:30          DEV       tps     rkB/s     wkB/s     dkB/s   areq-sz    aqu-sz     await     %util
20:35:31      nvme2n1   9514.00  98760.00 166464.00      0.00     27.88     10.49      1.10    100.00
20:35:31      nvme4n1   9445.00  98752.00 166416.00      0.00     28.07     11.27      1.19    100.00
20:35:31      nvme8n1   9471.00  98684.00 166348.00      0.00     27.98     10.90      1.15    100.00
20:35:31     nvme11n1   9477.00  98688.00 166388.00      0.00     27.97     10.63      1.12    100.00
20:35:31     nvme13n1    273.00      0.00  56320.00      0.00    206.30      0.86      3.15     11.60
20:35:31          md0  33225.00 394756.00 665604.00      0.00     31.91     62.53      1.88    100.00

Temp1 is a raid0 or 4 drives.
nvme13n1 is Temp2 and is not a raid.
And these are cloud volumes! :wink: