Max plots allowed per dst drives

[FVierra27]

An option to say this destination drive can only hold X number plots. This way it will not try to start another job with that destination drive. Would be really cool for set and forget.

[JoshuaEstes]

I agree, it's too often that I'm managing this by hand by removing the dst dir from config file and restarting plotman.

[hajes]

What reason is there not to use the archiving feature? Why do we need to reimplement and maintain all the archiving functionality at another layer where you are making often long term predictions about available space? If you have a particular need, perhaps we can address it.

it is kinda stupid don't you think? you don't top up already full tank at petrol station ;-)

it is core logic not to use full destination drive. why would you check free space if Plotman still uses full destination drive - it is waste of resources...plotting runs 7 hours and fails because destination drive is full.

it is poor excuse "use archiving function", why make it complicated?

do you think that most people have 10 drives + 20 archives?

normal user has one or perhaps three drives and expects the program run as suppose to. Simply put "IF DISK FULL, DON'T USE IT". I wonder developers would make such a mistake in first place.

[altendky]

@hajes, once again you show that you don't understand and you are unwilling to engage in good faith or learn. Rather you throw around insults. Yes, there are many reasons that people want to use dst in the way they do. There are many things we could have done differently. But, archiving is easy to use locally now. For anyone that is interested in understanding dst vs. archiving please consider reading the archiving wiki page.

[hajes]

@altendky imagine what you could achieve if you focus your energy on creativity/improvements instead of excuses/blame/bs/desperate defense of your mistakes ;-)

it looks like you guys are scared of facts and desperately defend your only truth :-P

I am not surprised that we buy "perfect" products nowadays with mentality like yours - buy our car, you don't need steering wheel, you can use hand brake instead.

[ICYou]

I think archiving is just a bit unintuitive. As you kind of expect dst to do what is achieved with archiving.

Initially with rsync and remote archiving it seemed a bit more complicated to setup than what is necessary for a simple local transfer. So I thought.

It was just a bit of confusion. Perhaps the readme could clarify better that in the simplest scenario you would leave out dst and go straight to archiving. Dst is only if you have a buffer drive.

I can also say that plotman has been serving me extremely well since replotting to plot NFT’s. It has been running non stop, outputting 50plots a day and steadily filling my drives. I just occasionally need to clear a drive or two.

Thanks for the hard work :)

[altendky]

I absolutely agree that the name 'dst' reasonably makes people think that that is a good place to specify the final resting place for plots. I have considered changing the name but haven't delved into that (yet). Yes, I should take another pass through the documentation (readme/wiki/make "real" documentation). Right now I'm trying to clean up the multiple plotter support as there are more coming that presumably people will want support for.

[cyperbg]

Guys, big news for you - this option actually exists:

Edit this:

    # Currently support override parameters:
    #     - tmpdir_max_jobs
    tmp_overrides:
            # In this example, /mnt/tmp/00 is larger than the other tmp
            # dirs and it can hold more plots than the default.
            "/media/username/evo_1tb":
                    tmpdir_max_jobs: 3
            "/media/username/evo_2tb_1":
                    tmpdir_max_jobs: 5
            "/media/username/evo_2tb_2":
                    tmpdir_max_jobs: 5
            "/media/username/evo_2tb_3":
                    tmpdir_max_jobs: 5
            "/media/username/evo_2tb_4":
                    tmpdir_max_jobs: 5 

[JoshuaEstes]

Correct, but there is no option for plots per destination directories. A 1TB drive holds 9 plots, it would be nice for plotman to know that and stop putting plots into that destination directory.

[cyperbg]

Ah I see, I misunderstood, apologies.

[JoshuaEstes]

We all do it ;)

[ICYou]

It would be nice to see this, it would solve a lot of manually managing disk space and copying plots.

[plexi32]

Would be interested in that too, as here the distribution beetween my different ist drives is quite uneven(4, 7, 8).

[hajes]

I second that.

Yesterday, one disk run out of the free space but Plotman keeps plotting to full destination drive ???

[altendky]

The archiving layer is meant to handle distributing plots to their final resting places on farming drives. dst drives are meant as a buffer layer between plotting and archiving. You can entirely comment out your dst configuration section, let the plots stay on the tmp drives, and let archiving move them from their to their final locations.

There are many justified reasons that people used dst to refer to final farming disks. The name, the wiki pages saying to, the hassle of setting up rsyncd for local archiving... etc. My apologies for the confusion and hassle. But, dst is not really the intended layer for distributing plots among multiple drives. Some of these issues have been addressed and you can easily setup local archiving without rsyncd as of v0.4 (June 10th, 2021). See the wiki page for an extended discussion of the what and why of archiving.

In my present batch of drives, plotman has filled 11+ drives "one by one" from two plotters without any intervention on my part so the feature of "distributing plots to fill farming drives" does exist. I do not personally bother with having any dst drives as buffers at this point. On one of my systems I do not specify dst drives at all. On the other, I have a tmp2 ramdisk for madMAx and use dst to direct the final plot back to the tmp drive. plotman then archives from my tmp drives (locally in one case, remotely in the other) to the farming drives.

Yes, people do find bugs that need to be fixed. Yes, there are still many features to add to plotman. Yes, it works well for many people as is. Yes, I am happy to help people get to a working setup either here or on Keybase if they want to work with me to do so.