Delete for replot #870
Delete for replot #870
Conversation
| relative_path=$(realpath --canonicalize-missing --relative-to="${site_root}" "${full_destination}") | ||
| url_root="rsync://${user}@${host}:${rsync_port}/${site}" | ||
| "${command}" ${options} "${source}" "${url_root}/${relative_path}/" | ||
| ssh -p "${ssh_port}" "${user}@${host}" "ls -1U ${site_root}/${replot_glob}.plot | head -n 1 | xargs rm -fv" |
There was a problem hiding this comment.
Is this line the only change? Could it just be added to the existing targets with replot_glob being optional (and probably a different name) and execute only if specified? Is there a reason to use xargs over command substitution?
Not that this is a problem, but to make sure I understand, the expectation is to delete one plot from any archive drive and that the user will have consistent and separate directories across all archival drives for to-be-deleted plots vs. being-created plots. For example, I have */original/*.plot that I will end up deleting and I am now plotting to */pool.xch<contract address here>/*.plot. So, my replot_glob would be */original/*. Also, in a decade when we all need k33 and our drives just refuse to die we can use this with the plot-k32- as in your example and replace with k33. And in the end, the user just has to think about and be sure to setup the cross-archive-drive consistency or hazard deleting the plots they are creating etc.
Just to write it out, not to say there's a problem, this does require the user to provide a single plot worth of free space prior to this mechanism "working". That does avoid the complexity of the space check having to account for a plot that could be deleted. This seems like a good thing to avoid and it comes at a very low cost, though it does need to be made clear.
Anyways, a good bit of text but mostly just me thinking out loud so you can make sure I'm understanding properly.
As always, thanks for the work and the contribution.
There was a problem hiding this comment.
You've understood the intent precisely.
The additional 'deletion' line is the only extra - created a separate target for simplicity and was adapted from a comment in the plotting forum without too much consideration.
You're right - the user will need to be aware of what it is doing re: deleting initial plot and construction of the glob but as you've pointed out it is a fairly 'simple' solution.
There was a problem hiding this comment.
Since this is easy, and other solutions would probably be hard, I wouldn't push back on this. However, it seems far from intuitive, so I'd like it if everything that's been written up here explaining what's going on is converted into documentation somewhere nearby...?
As for longer-term solutions, I think there are a variety of plot-management tasks which would be cool to eventually support -- replacing OG plots with NFT plots, replacing plots that have won blocks with new plots, migrating from k32 to larger, "defragging" empty space on plot drives, migrating plots from specified drives elsewhere to enable them to be decommissioned, etc. This would really be a "plot management" rather than the "plotting management" system plotman has been, but it would need to interface closely with the traditional plotman.
This adds a target defintion which deletes a single file based on a glob after archiving. This means that there is sufficient space for the next archiving operation to take place. It assumes that there is sufficient space (through the deletion of a single plot) before beginning and that archiving is faster than plot generation.