[Suggestion] Multiple final destinations (for JBOD setups)

[ghost]

Would be great if we could specify multiple final destination directories/drives and have the plotter skip destinations that become full ;)

[mist0706]

I think we need to keep this as a plotter and not a plotting manage or the scope becomes too big. It's trivial to set up a bash or python script to do this. No need to bloat the plotter and introduce dependencies.

[SebMoore]

I agree. That sort of thing is best left to a script and/or plot manager (plotman, Swar etc.) This project should just be the barebones plotter - best to focus on performance and bug fixes at the moment rather than admittedly useful, but unnecessary, features.

[madMAx43v3r]

Yeah what @mist0706 and @VertiHydro said

[GTANAdam]

Agreed. I already have a working clone of plotman written in Golang, single executable without any python ridiculous dependencies

[jneuhauser]

Do you plan to open source your Go plotman clone?

[GTANAdam]

Do you plan to open source your Go plotman clone?

Yes, this is planned.

[reb0rn21]

Is anyone working on scripting this, + next plot as soon first start to be copied?

[PsychoLogiKal]

Honestly the check if full isn't needed but seriously the ability to use 2 destination directories and switch back and forth every other between them really is a needed feature considering SMR drives are slower than you can plot.......it creates a bottle neck which wouldn't be as much of an issue if it switched between 2 or more specified directories in series.

[tobernguyen]

Would be great if we could specify multiple final destination directories/drives and have the plotter skip destinations that become full ;)

Lightweight wrapper script I wrote to address this (and some other pains I have): https://github.com/tobernguyen/madmax-manager

[jneuhauser]

As from the old days I've plotman on my plotter machines, I use the archive function of plotman to move my plots in place... Since plotman v0.4 the archive part does also support local archive dirs...

So i run one tmux session for chia-plotter: chia_plot ... -t /mnt/tmp -d /mnt/dst -n -1

And in another tmux session i ran: plotman archive

plotman.yaml:

...
directories:
  dst:
    - /mnt/dst
archiving:
  target: rsyncd
  env:
    site_root: /mnt/farm
    user: farmer
    host: 192.168.70.210
    rsync_port: 12000
    site: chia
...

[zmej420]

Hey, I'd like this feature very much as well. I have a suggestion about how we can get a middle-ground between madmax being a "plot manager" and a "plotter."

Perhaps there could be a flag to fork if plotting is finished and we are only waiting for the final transfer. This way a script running sequential chia_plot commands will move on to the next drive while a transfer finishes. Another possibility is to fork in general for transfers to make it trivial for a script to know whether chia_plot is plotting or transferring. At the moment a script needs to read the chia_plot output to determine if it's time to start plotting the next drive, but with just a minor change like I've mentioned, a script could just look for if there is a running instance of the primary madmax plotting software.

[zmej420]

Honestly the check if full isn't needed but seriously the ability to use 2 destination directories and switch back and forth every other between them really is a needed feature considering SMR drives are slower than you can plot.......it creates a bottle neck which wouldn't be as much of an issue if it switched between 2 or more specified directories in series.

This is also a very good point, albeit somewhat tangential to the original feature request. I do my best to only plot onto directly attached SAS or SATA disks, but occasionally I end up plotting to NAS or USB drives which leads to severely dimished plots per day. Scripting the alternation is of course possible, but much messier than it could be if there was some support in chia_plot. Once again, as my last post way saying, this doesn't need to be implemented fully, but there could be some sort of flag and communication system added to make it so a script can manage this without parsing logs.

[GTANAdam]

In my opinion, there must be a clear and solid line between a "plot manager" and "plotter", initiating plotting instances can invoked via a plot manager, having a mix of both would void the purpose of a plot manager and further complicate the development and maintenance of the plotter. so it is better to keep it the way it actually is and develop a 3rd party plot manager.