IIRC, long time ago, when there was no MM, and there was a need to stagger those chia plotters, when tmp file was full (staggering went out of whack), it was giving a similar error. I think that it was not aborting, just patiently waiting for the user to remove some junk. Maybe this is the same thing? (Although, I am not really certain whether it was chia or MM waiting. That ‘Retrying in 5’ suggests that all is good, but the free disk space is missing.)
The output says “Only wrote X at offset Y” that implies that Y size file is sitting there, and copy process is going on, but when it hits that X byte, it may be out of space.
The second output is kind of irrelevant, as we know that the file is not sound.
Although, take a look at those chia charts (lower right) - Grafana. If you switch to k36, maybe Chia will put your name in the tooltip there
Do you mean physically broken?
Or do you mean insufficient memory?
Something else?
I give the job 8x the default ram, via the “-b 27112” option (the default is 3389).
I also the job 14 threads (default is 2), on this 16 core computer (the other 14 is the madmax plotting job, leaving 4 threads for the OS).
Both of the computers have 64 GB of RAM.
They rarely go over 32 GB, according to taskmrg.
Perhaps I should double the -b option, again, to 54224?
the 2nd reason for aborting plotts by my system was inode errors at the plotting SSD, if ur using ubuntuu try, but i cant remember if i got also this error messages.
sudo fsck -a -v
if ur got errors about inodes then this was the problem
There is no way that I was out of disk space, for three reasons:
I was periodically checking (especially near the section where the job failed 3 times before), and it never got close to 1 TB remaining.
I was running a madmax K34 plot, (actually, several K34s completed during the K35 processing, and all of the K34 plots were good).
Just in case my computers favored madmax in a temp space conflict, where the K34 would be successful, please keep in mind that I got the same errors 3 times when I ran the K35 solo.
During the plot creation disk utilization constantly fluctuates, and there are short spikes here and there. When we look at what has to be done, it is obvious to us that a move would be good enough, but the code may be just too generic, and will just duplicate a file for no reason, just to kill the original once that process is done. Just saying.
Not sure how soon you caught that error, but maybe you could run resource monitor with some 30 secs interval to check the free space.
I do not have the temp space for K36 (which would be over 4 TB).
K35 requires just north of 2 TB of temp space, which I accomplish via two 2 TB NVMe drives in a RAID 0.
I could direct the K36 job to a mechanical drive, and check on it in a month.
However, I believe that chia.exe has a maximum “-k” value of “35” (based on what the GUI offers).
$ chia plots create --help
…however, shows no -k value limit. Perhaps K36 is doable?
That chart has k36 column with the respective percentage. So, there has to be at least one such plot out there.
If you think about it, one should be able to specify k-full-drive, and have the plotter fill all the space on that drive, even if would that mean somehow concatenating k32 plots, and having the last one partial. The very first attacks on MM were with respect to dropped hashes (speed optimization), so I would think that partial k32 should be possible, as such k-full_drive shold be an option.
Maybe you can run memtest86 first just to exclude bad RAM possibility? Although, as @amarena stated, two boxes with the same problem, so that is rather not likely. It rather suggests that the problem is with your setup, not with the H/w.
