<html><head></head><body>For what it’s worth, I once created a stripe volume on ram disks. After the initial creation of the bricks, I made a copy of all the files gluster created. After reboot, the files are copied back to the ramdisk before gluster starts, so basically after a reboot you have an empty gluster volume once again.<br>
<br>
The performance was really good. Maxed out the dual 10GbE on each server.<br>
<br>
If you need really-high IOPS to a file that may be too big for a ramdisk in 1 machine, consider a stripe volume of multiple ram disks.<br>
<br>
<br>
On Apr 5, 2016, at 8:53 AM, Sean Delaney <sdelaney@cp.dias.ie> wrote:<br>
<br>
Hi all,<br>
<br>
I'm considering using my cluster's local scratch SSDs as a shared filesystem. I'd like to be able to start glusterfs on a few nodes (say 16), run a HPC job on those same nodes (reading/writing on glusterfs), copy the final result off to the panasas storage, and shut down glusterfs until next time.<br>
<br>
I'm interested in this because my workload has shown strong performance on the SSDs, which I'd like to scale out a little.<br>
<br>
Ultimately, I might be interested in setting up a tiered glusterfs using the SSDs as the hot tier. Again, the ability to bring the filesystem up and down easily would be of interest.<br>
<br>
Example cluster: 32 nodes, 1.5 TB SSD (xfs) per node, separate HDD for OS, panasas storage.<br>
<br>
Thanks<br>
<br>
_______________________________________________<br>
Gluster-users mailing list<br>
Gluster-users@gluster.org<br>
http://www.gluster.org/mailman/listinfo/gluster-users<br>
<br>
<img src="http://t.sidekickopen04.com/e1t/o/5/f18dQhb0S7ks8dDMPbW2n0x6l2B9gXrN7sKj6v4LN9-W2z8_hM5wLWr-N7dSKlbd3_yKW6jq8hk1k1H6H0?si=6102096971038720&pi=239D8B55-B0D9-457A-ACCD-34142ADE8B0A" width="1" height="1" style="display:none!important"></body></html>