How to best utilize disk space

I have some confusion on the Plotsize. I have read that smaller blocks cannot win. On the other hand, I have read that smaller plots have a smaller chance to win. What is true?

Reason behind is that I have 20 or so harddrives and the very most of them gave a couple of gigs left. Roughly 15-75gb. I wonder if I can use that space better.
example plotfields

LG,

Julian from KryptoMine

The smallest plot you can use is k32, apx size is 106gb.
A k33 apx twice the size will win apx twice as much.
A k34 apx twice the size of k33, will win apx twice as much as k33.

You can use those small spaces to store split k32, but I don’t do this so can’t advise, but I’m sure someone else will.

Its a small percentage, under 1% if you have 16tb disks, so more hassle than I’m bothered with.

1 Like

Only possibilty I know is to use a raid config.

Seems true. Didnt view it from that angle. It seems that those 75gb jump to your mind if you look at it.

no way will I do a raid config.

1 Like

I’m sure I’ve read of ppl doing it without raiding the whole drive, but as I said, I can’t be bothered.

Maybe this helps you:

1 Like

thanks for he resource, You mean creating a new spanned volume for the rest of the capacity?

Any plot of size K32 or lager can win (in the future, the minimum might be K33 – but that is probably a few years from now).

As I understand the way Chia operates, it is that an initial test is sent out, and only plots that pass that test will move on to the next phase, where a winner will be found. So the more plots you have, the more chances you have of them moving on to the second phase.

However, there is also a disadvantage to smaller plots.

If a K32 plot goes up against a K33 plot in the second phase, then the K33 plot has twice as many chances of beating out the K32 plot. But if all you have are K33 plots, then on average, ½ as many of your plots will make it to the second phase. But the ones that do have a better shot at winning.

And so it goes for K34 plots, etc.

So my suggestion is to stuff as many plots as possible onto each drive.
There are chia calculators (seach duckduckgo.com for one) where you enter the size of your drive, and it will give you info on how many of each size plot combinations will fit on your drive.

As to the leftover space:
The only way that I know of utilizing that space (short of using a non-standard file system), is to use a RAID 0 or RAID JBOD array.

The issue with either of the above RAID options is that if you lose a single drive, then you lose the plots on all drives that are in that RAID.

So you will be taking on a bit of risk, especially if you put dozens of drives in a single RAID 0 or RAID JBOD.

Perhaps you can figure out combinations of on 2, 3, or 4 drives that, if put in a RAID, will allow you to maximize all available space. Those RAIDs will not be too risky, because if you have a drive failure, you would need only to repopulate the plots lost on the remaining drives from the RAID. And with the help of a Chia calculator, you can probably be very efficient with filling up the drives in the RAID.

RAID 0 will likely give you better performance vs RAID JBOD.

Lastly, I do not believe that you can create a USB based RAID – at least not in Windows.
For Linux, maybe it is possible, because Linux seems to make everything possible.

If I got anything wrong, someone please clarify.

Exactly, I have never done this but it sounds promising to me.

It’s not a disadvantage considering

A. A k33 is twice the size of a k32 so you have half as many.
B. More than one plot can get the block reward and receive 2 xch.

wouldnt that mean that a k31 plot can win a block in twice the time?
In reality that will be never for one small plot. But adding them up, 10tb of small plots should be equal to 10tb of large plots (required processing power nt considered)

No, a k32 is the smallest size accepted.
And it wouldn’t win faster even if they were accepted as its half the size so contains half the proofs.

The only real reasons to use bigger plots are if they fill the disk size better, or to future proof for / if we move to k33.

Yes, and they are roughly.

1 Like

Look at this from a slightly different perspective. Your chances of winning are related to disk space your plots cover. Whether you use smaller or bigger plots, it doesn’t matter, if they cover the same amount of space.

There was some discussion before that potentially bigger plots may have a slightly higher chance, but as far as I remember that was way sub one percent, so as @Bones said, not worth wasting time on thinking about it. Basically, you reboot your box once, and that will put a much bigger dent in your chances than you gain through countless hours of dealing with this problem.

I’m sure most of you have seen this calculator, and I have questions.

https://plot-plan.chia.foxypool.io/

I have mostly 14 and 16 tb drives. I was thinking about buying some more drives, and moving plots around to allow for some k33 and k34 plots. I understand that k32 plots might not be usable in the future. But ignoring that.

Let’s say you have a 14tb hard drive. It will fit 128 k32 plots, according to the calculator a better utilization of space would be 73 K32 plots and 27 k33 plots. If I understand this correctly to properly compare the chances of either configuration have a winning plot, I’d multiply 27 x 2 and get 54 and then add that to 73 which would be 127. So instead of 128 chances to win on this drive I’d now have 127. How is that a better utilization of space? Is it because a k33 plot likely wins against a k32 plot?

All other drive sizes and plot type combinations breakdown basically this same way. What seems like less actual chances of winning per drive, even though space is better utilized.

k33 should have double the chance to win of a k32 but double the size as well.
a few considerations go into this for me:

  • You need a lot of temp space meaning you need to either buy large ssd’s and put them into a raid or you need some other way to plot on a large temp space (I currently scrape old 500 gb laptop nvmes for free.)

  • im not entirely sure if minmaxing like this works easily. Looks like introducing further complications/interfering while plotting. For me, i currently hook up a drive and it gets filled automatically with k32 blocks.

  • afterwards at least for big farms, the lookup time should be reduced with larger blocks I think.

However, you can use Windows’ ‘Storage Spaces’ to create virtual drives that occupy all the spare space on all your other drives. On my systems with ~100TB of plots, this allows me to configure a virtual drive per system with all the spare chunks of free space from all the drives attached to it, and gives me space for another 10-12 plots. Not much, granted, but better than nothing.

I don’t care if losing one of the drives makes me lose the virtual drive because it isn’t storing that many plots and therefore the loss is small. I would be more upset about losing the plots on the actual physical drive that failed!

2 Likes

I tried to do this and I’m having some trouble. At first it all seemed to work. I created virtual hard drives in the empty spaces on some of my drives. Put them all into a Raid-0 with Storage spaces. And everything seemed good, it worked! Then reboot and it all goes away. Well, then I thought, duh! The Virtual hard drives have to be mounted. I mounted each of them, and even though Windows sees the Raid-0 drive again, it’s completely empty, like a brand new unformatted disk. Since the volume isn’t that large, losing the plots inside of it after each reboot is an annoyance more than a tragedy. But still, it’s annoying. Does anyone know what I might be doing wrong?

Make sure all of the virtual hard disks are mounted. If you mount all bar one (say) then the storage space drive will still be visible but the contents will either be incomplete or empty.

It’s easier to use a script to mount the drives than to do it manually. I can post the script if you want.

I’d love to see your script. Part of me is wondering if because it takes a minute to mount the virtual hard drives manually, if only being partially mounted for several minutes is corrupting the array somehow?

Create a new plain text file somewhere on your system can name it ‘MountImages.ps1’ or something similar. Edit the file and add the following line for one image file (your path and filename will vary);

mount-diskimage -imagePath "C:\YourFolder\YourImageFile.vhdx"

Add as many commands on seperate lines as you have image files. Save the file.

When you execute the script, you may have to do so as Administrator - the easiest way I do this is to find the ‘Windows Powershell ISE’, right click the shortcut and choose ‘Run as Administrator’. Then, open the ‘MountImages.ps1’ file you created above, and click the green ‘run’ triangle button on the top bar (or press ‘F5’).

You should see messages mounting each of the images in turn, after which your Storage Spaces drive should be visible and the contents should be there (assuming you have mounted all the files of course!).

I haven’t bothered automating this at startup as my machines stay up for months on end usually, but you could.