<font size=2 face="sans-serif">see a mdtest for a default block size file
system ...</font><br><font size=2 face="sans-serif">4 MB blocksize..</font><br><font size=2 face="sans-serif">mdata is on SSD </font><br><font size=2 face="sans-serif">data is on HDD ... which is not
really relevant for this mdtest ;-) </font><br><br><br><font size=3 face="Courier">-- started at 09/07/2018 06:54:54 -- </font><br><br><font size=3 face="Courier">mdtest-1.9.3 was launched with 40 total
task(s) on 20 node(s) </font><br><font size=3 face="Courier">Command line used: mdtest -n 25000 -i 3
-u -d /homebrewed/gh24_4m_4m/mdtest </font><br><font size=3 face="Courier">Path: /homebrewed/gh24_4m_4m </font><br><font size=3 face="Courier">FS: 10.0 TiB Used FS: 0.0%
Inodes: 12.0 Mi Used Inodes: 2.3% </font><br><br><font size=3 face="Courier">40 tasks, 1000000 files/directories </font><br><br><font size=3 face="Courier">SUMMARY: (of 3 iterations) </font><br><font size=3 face="Courier"> Operation
Max
Min Mean
Std Dev </font><br><font size=3 face="Courier"> ---------
---
--- ----
------- </font><br><font size=3 face="Courier"> Directory creation:
449160.409 430869.822 437002.187
8597.272 </font><br><font size=3 face="Courier"> Directory stat :
6664420.560 5785712.544 6324276.731
385192.527 </font><br><font size=3 face="Courier"> Directory removal :
398360.058 351503.369 371630.648
19690.580 </font><br><font size=3 face="Courier"> File creation :
288985.217 270550.129 279096.800
7585.659 </font><br><font size=3 face="Courier"> File stat
: 6720685.117 6641301.499 6674123.407
33833.182 </font><br><font size=3 face="Courier"> File read
: 3055661.372 2871044.881 2945513.966
79479.638 </font><br><font size=3 face="Courier"> File removal :
215187.602 146639.435 179898.441
28021.467 </font><br><font size=3 face="Courier"> Tree creation :
10.215 3.165
6.603 2.881
</font><br><font size=3 face="Courier"> Tree removal :
5.484 0.880
2.418 2.168
</font><br><br><font size=3 face="Courier">-- finished at 09/07/2018 06:55:42 --</font><br><br><div><br><br><br><font size=2 face="sans-serif">Mit freundlichen Grüßen / Kind regards</font><br><br><font size=2 face="sans-serif"> <br>Olaf Weiser<br> <br>EMEA Storage Competence Center Mainz, German / IBM Systems, Storage Platform,<br>-------------------------------------------------------------------------------------------------------------------------------------------<br>IBM Deutschland<br>IBM Allee 1<br>71139 Ehningen<br>Phone: +49-170-579-44-66<br>E-Mail: olaf.weiser@de.ibm.com<br>-------------------------------------------------------------------------------------------------------------------------------------------<br>IBM Deutschland GmbH / Vorsitzender des Aufsichtsrats: Martin Jetter<br>Geschäftsführung: Martina Koederitz (Vorsitzende), Susanne Peter, Norbert
Janzen, Dr. Christian Keller, Ivo Koerner, Markus Koerner<br>Sitz der Gesellschaft: Ehningen / Registergericht: Amtsgericht Stuttgart,
HRB 14562 / WEEE-Reg.-Nr. DE 99369940 </font><br><br><br><br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">"Andrew Beattie"
<abeattie@au1.ibm.com></font><br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">gpfsug-discuss@spectrumscale.org</font><br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">09/21/2018 02:34 AM</font><br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [gpfsug-discuss]
Metadata with GNR code</font><br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">gpfsug-discuss-bounces@spectrumscale.org</font><br><hr noshade><br><br><br><font size=2 face="Arial">Simon,</font><br><font size=2 face="Arial"> </font><br><font size=2 face="Arial">My recommendation is still very much to use
SSD for Metadata and NL-SAS for data and</font><br><font size=2 face="Arial">the GH14 / GH24 Building blocks certainly
make this much easier.</font><br><font size=2 face="Arial"> </font><br><font size=2 face="Arial">Unless your filesystem is massive (Summit
sized) you will typically still continue to benefit from the Random IO
performance of SSD (even RI SSD) in comparison to NL-SAS.</font><br><font size=2 face="Arial"> </font><br><font size=2 face="Arial">It still makes more sense to me to continue
to use 2 copy or 3 copy for Metadata even in ESS / GNR style environments.
The read performance for metadata using 3copy is still significantly
better than any other scenario.</font><br><font size=2 face="Arial"> </font><br><font size=2 face="Arial">As with anything there are exceptions to
the rule, but my experiences with ESS and ESS with SSD so far still maintain
that the standard thoughts on managing Metadata and Small file IO remain
the same -- even with the improvements around sub blocks with Scale V5.</font><br><font size=2 face="Arial"> </font><br><font size=2 face="Arial">MDtest is still the typical benchmark for
this comparison and MDTest shows some very clear differences even
on SSD when you use a large filesystem block size with more sub blocks
vs a smaller block size with 1/32 subblocks</font><br><font size=2 face="Arial"> </font><br><font size=2 face="Arial">This only gets worse if you change the storage
media from SSD to NL-SAS</font><br><font size=3 color=#80803f face="Arial"><b>Andrew Beattie</b></font><br><font size=2 face="Arial"><b>Software Defined Storage - IT Specialist</b></font><br><font size=1 color=#3f8080 face="Arial"><b>Phone: </b></font><font size=1 face="Arial">614-2133-7927</font><br><font size=1 color=#3f8080 face="Arial"><b>E-mail: </b></font><a href="mailto:abeattie@au1.ibm.com"><font size=1 color=#4f4f4f face="Arial"><u>abeattie@au1.ibm.com</u></font></a><br><font size=2 face="Arial"> </font><br><font size=2 face="Arial"> </font><br><font size=2 face="Arial">----- Original message -----<br>From: Simon Thompson <S.J.Thompson@bham.ac.uk><br>Sent by: gpfsug-discuss-bounces@spectrumscale.org<br>To: "gpfsug-discuss@spectrumscale.org" <gpfsug-discuss@spectrumscale.org><br>Cc:<br>Subject: [gpfsug-discuss] Metadata with GNR code<br>Date: Fri, Sep 21, 2018 3:29 AM<br> </font><p><font size=2 face="Arial">Just wondering if anyone has any strong views/recommendations
with metadata when using GNR code?</font><p><font size=2 face="Arial"> </font><p><font size=2 face="Arial">I know in “san” based GPFS, there is a recommendation
to have data and metadata split with the metadata on SSD.</font><p><font size=2 face="Arial"> </font><p><font size=2 face="Arial">I’ve also heard that with GNR there isn’t
much difference in splitting data and metadata.</font><p><font size=2 face="Arial"> </font><p><font size=2 face="Arial">We’re looking at two systems and want to
replicate metadata, but not data (mostly) between them, so I’m not really
sure how we’d do this without having separate system pool (and then NSDs
in different failure groups)….</font><p><font size=2 face="Arial"> </font><p><font size=2 face="Arial">If we used 8+2P vdisks for metadata only,
would we still see no difference in performance compared to mixed (I guess
the 8+2P is still spread over a DA so we’d get half the drives in the
GNR system active…).</font><p><font size=2 face="Arial"> </font><p><font size=2 face="Arial">Or should we stick SSD based storage in as
well for the metadata pool? (Which brings an interesting question about
RAID code related to the recent discussions on mirroring vs RAID5…)</font><p><font size=2 face="Arial"> </font><p><font size=2 face="Arial">Thoughts welcome!</font><p><font size=2 face="Arial"> </font><p><font size=2 face="Arial">Simon</font><p><tt><font size=2>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org</font></tt><tt><font size=2 color=blue><u><br></u></font></tt><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" target="_blank"><tt><font size=2 color=blue><u>http://gpfsug.org/mailman/listinfo/gpfsug-discuss</u></font></tt></a><br><font size=2 face="Arial"> </font><br><tt><font size=2>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org<br></font></tt><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss"><tt><font size=2>http://gpfsug.org/mailman/listinfo/gpfsug-discuss</font></tt></a><tt><font size=2><br></font></tt><br><br></div><BR>