3 Levels of copying, instead of 2?

[number435398]

So, if you are plotting on a pure ram drive of around 240gb, the problem that you will have is that after the plot has been created, you have to copy it to a drive fast enough such that it doesn't backup the next plot creation. If it doesn't copy fast enough (such as because you're trying to copy to an external USB drive) the entire program crashes because it fills up the RAM drive and errors out before the file has been moved off the RAM drive. So, yes, telling it to then copy it to the second drive, usually as an NVME drive helps, but who wants to store all their plots on an nvme drive? I'm advocating the addition of a 3rd drive to copy things to. Plot on a RAM drive, copy to an NVME to avoid filling up the RAM drive, then have it copy from the NVME to, say, an external USB all in the same process.

[Dartellum]

You can make your own script to move the plot from the NVMe drive. The plotter does not need to do this type of housekeeping. I wrote a bash script that will move plots and even find a drive with space out of an array of drives. See here: https://github.com/Dartellum/chia-madmax-plot_loop.

[number435398]

Considering the use of RAMdrives to increase speeds it seems like implementing it into this program would be ideal rather than running a separate script. Elegance and simplicity.

[llamasoft]

Alternate suggestions:

• Retry on disk write failures as it may be eventually be resolved by a background plot move completing. (This is how the main chiapos implementation handles it.)
• Only allow one background plot move at a time, regardless of --waitforcopy value. This would still allow background plot moves but prevent building up a backlog of plots because of the destination drive being too slow.
• Add swap space to your system using your NVMe drive. If memory pressure gets too high, tmpfs is allowed to use swap.

But the bottom line is that adding additional levels of copying only delays your problem, not solves it.
Moving to NVMe first frees up RAM the fastest, but if you're still generating plots faster than your final drive(s) can be written to then eventually your NVMe drives will fill up too.

[madMAx43v3r]

--waitforcopy should prevent running out of RAM right?

[number435398]

Alternate suggestions:

* Retry on disk write failures as it may be eventually be resolved by a background plot move completing.  (This is how the main chiapos implementation handles it.)

* Only allow one background plot move at a time, regardless of `--waitforcopy` value.  This would still allow background plot moves but prevent building up a backlog of plots because of the destination drive being too slow.

* Add swap space to your system using your NVMe drive.  If memory pressure gets too high, tmpfs is allowed to use swap.

But the bottom line is that adding additional levels of copying only delays your problem, not solves it. Moving to NVMe first frees up RAM the fastest, but if you're still generating plots faster than your final drive(s) can be written to then eventually your NVMe drives will fill up too.

No, 2 levels of copies would cover it in some situations. If you have a 250gb RAM drive, it'll fill up within just a couple of minutes of the second plot. So you have to finish that copy off the ramdrive within just a couple of minutes (while the overall 2nd plot creation will take 20+ minutes). So, if you immediately move the plot to an NVME, you can get it off the ram drive. Then you've got 15+ mins to get it off the nvme to a usb hdd which should be plenty of time to clear it before the next plot is done.

[number435398]

--waitforcopy should prevent running out of RAM right?

Yes, that would be very helpful along these lines as well. I still think the 2 levels of copying could be helpful as well, but there would definitely be some overlap in their value.