<html><body><p>GPFS proper (as opposed to GNR) isn't particularly picky about block devices. Any block device that GPFS can see, with help from an nsddevices user exit if necessary, is fair game, for those willing to blaze new trails. This applies to "real" devices, e.g. disk partitions or hardware RAID LUNs, and "virtual" ones, like software RAID devices. The device has to be capable to accepting IO requests of GPFS block size, but aside from that, Linux kernel does a pretty good job abstracting the realities of low-level implementation from the higher-level block device API. The basic problem with software RAID approaches is the lack of efficient HA. Since a given device is only visible to one node, if a node goes down, it takes the NSDs with it (as opposed to the more traditional twin-tailed disk model, when another NSD server can take over). So one would have to rely on GPFS data/metadata replication to get HA, and that is costly, in terms of disk utilization efficiency and data write cost. This is still an attractive model for some use cases, but it's not quite a one-to-one replacement for something like GNR for general use.<br><br>yuri<br><br><img width="16" height="16" src="cid:1__=07BBF541DFE170D38f9e8a93df938690918c07B@" border="0" alt="Inactive hide details for "Jaime Pinto" ---06/13/2016 09:11:38 AM---I just came across this presentation on "GPFS with underlyi"><font color="#424282">"Jaime Pinto" ---06/13/2016 09:11:38 AM---I just came across this presentation on "GPFS with underlying ZFS block devices", by Christopher H</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">"Jaime Pinto" <pinto@scinet.utoronto.ca></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">"gpfsug main discussion list" <gpfsug-discuss@spectrumscale.org>, </font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">06/13/2016 09:11 AM</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">Re: [gpfsug-discuss] GPFS on ZFS?</font><br><font size="2" color="#5F5F5F">Sent by: </font><font size="2">gpfsug-discuss-bounces@spectrumscale.org</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><tt>I just came across this presentation on "GPFS with underlying ZFS <br>block devices", by Christopher Hoffman, Los Alamos National Lab, <br>although some of the<br>implementation remains obscure.<br><br></tt><tt><a href="http://files.gpfsug.org/presentations/2016/anl-june/LANL_GPFS_ZFS.pdf">http://files.gpfsug.org/presentations/2016/anl-june/LANL_GPFS_ZFS.pdf</a></tt><tt><br><br>It would be great to have more details, in particular the possibility <br>of straight use of GPFS on ZFS, instead of the 'archive' use case as <br>described on the presentation.<br><br>Thanks<br>Jaime<br><br><br><br><br>Quoting "Jaime Pinto" <pinto@scinet.utoronto.ca>:<br><br>> Since we can not get GNR outside ESS/GSS appliances, is anybody using<br>> ZFS for software raid on commodity storage?<br>><br>> Thanks<br>> Jaime<br>><br>><br><br><br><br><br> ************************************<br> TELL US ABOUT YOUR SUCCESS STORIES<br> </tt><tt><a href="http://www.scinethpc.ca/testimonials">http://www.scinethpc.ca/testimonials</a></tt><tt><br> ************************************<br>---<br>Jaime Pinto<br>SciNet HPC Consortium - Compute/Calcul Canada<br></tt><tt>www.scinet.utoronto.ca</tt><tt> - </tt><tt>www.computecanada.org</tt><tt><br>University of Toronto<br>256 McCaul Street, Room 235<br>Toronto, ON, M5T1W5<br>P: 416-978-2755<br>C: 416-505-1477<br><br>----------------------------------------------------------------<br>This message was sent using IMP at SciNet Consortium, University of Toronto.<br><br>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org<br></tt><tt><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a></tt><tt><br><br></tt><br><BR>
</body></html>