I could not find a filesystem or filesystem overlay that I was happy with for storing plots. They all had overhead or downsides I didn’t find acceptable. All I wanted was a filesystem that could survive disk failures losing only the plots on that disk (not the entire pool), but still combine any remaining space at the end of each disk for more plots.
i much prefer a good large jounraled filesystem with
perfectly suited for xfs with appropriate flags. on each disk
mounting them.
wrangling the lot of drives “folders” together with the proven multi-hard drive disk filesystem (mhddfs) combines directories or hard disks on a union filesystem to create a single, large, virtual filesystem that you can use both locally and via Samba or NFS.
it turns many folders into 1 simple folder… and u can specify size regulations on where to store plots automaticaly. so u only need worry about 1 folder.
that way if a drive dies… i only loose the plots on that drive…
no raid rebuilds ect
the plot data isnt mission critical and can be replotted.
i did the hard thing for a while… srsly look into mhddfs changed my life
Journaling only matters when writing data, once the drive is full of plots, the journal feature serves no purpose. PlotFS exposes any number of drives as one folder. In fact, PlotFS does not support folders at all. I’m not familiar with mhddfs, but it seems it won’t split files across drives (it will just move the file to a drive with more space) which is the main feature I wanted. Exposing a bunch of drives as one folder via PlotFS and not wrangling mounts and folders sounds way easier to me.
What about Hadoop.
Hdfs. With xfs laid Ontop.
Perhaps some interesting compression possibilities aswell… somthing like 4-1 compression… so a plot reduced by 75 percent would certainty shake things up…. That’s read even faster….
I’m trying to reduce harvester seek times. And squeez every drop of space out.
it’s my understanding using Hadoop hdfs u can compress a files at the block lvl and distribute a file to storages among multiple servers seamlessly while also handling replication for error handling. Logging.
I gues it accomplishes such drastic compression by splitting the blocks up first. And compressing from there… Leaving the extension in tact…
Some super heavy reading tho. Iv only just made this connection. Still a lot to learn.
The plots are basically incompressible. They most you can possibly compress a plot with traditional block compression is about 2%. It’s not a matter of better compression, It’s a matter of information theory. There is no such “game changer” out there, we can prove it mathematically. I thought about adding this to plotfs to get that 2%, but I’m waiting to see what the next plot format looks like. When Chia releases that I’ll take another look at possible additional compression. (I have some ideas about how to restructure the files for additional gains, but it probably won’t pan out)
hdfs+ Hadoop will add overhead and/or make it much more likely you will loose extra data when a drive fails. Plotfs has virtually zero overhead. if you want to “squeeze every drop of space out” PlotFS is the only game in town. PlotFS probably will also be very difficult to beat for seek times.
Believe me, if there as a magic compression, or combination of files systems, It would have already been done, and everybody would already know bout it. That’s why I made this.