<div dir="ltr">Hi,<div><br></div><div>Metadata I/Os will always be smaller than the usual data block size, right?</div><div>Which version of GPFS?</div><div><br></div><div>Regards,</div><div>Alex</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 23, 2022 at 10:26 AM Uwe Falke <<a href="mailto:uwe.falke@kit.edu">uwe.falke@kit.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear all,<br>
<br>
sorry for asking a question which seems not directly GPFS related:<br>
<br>
In a setup with 4 NSD servers (old-style, with storage controllers in <br>
the back end), 12 clients and 10 Seagate storage systems, I do see in <br>
benchmark tests that  just one of the NSD servers does send smaller IO <br>
requests to the storage  than the other 3 (that is, both reads and <br>
writes are smaller).<br>
<br>
The NSD servers form 2 pairs, each pair is connected to 5 seagate boxes <br>
( one server to the controllers A, the other one to controllers B of the <br>
Seagates, resp.).<br>
<br>
All 4 NSD servers are set up similarly:<br>
<br>
kernel: 3.10.0-1160.el7.x86_64 #1 SMP<br>
<br>
HBA: Broadcom / LSI Fusion-MPT 12GSAS/PCIe Secure SAS38xx<br>
<br>
driver : mpt3sas 31.100.01.00<br>
<br>
max_sectors_kb=8192 (max_hw_sectors_kb=16383 , not 16384, as limited by <br>
mpt3sas) for all sd devices and all multipath (dm) devices built on top.<br>
<br>
scheduler: deadline<br>
<br>
multipath (actually we do have 3 paths to each volume, so there is some <br>
asymmetry, but that should not affect the IOs, shouldn't it?, and if it <br>
did we would see the same effect in both pairs of NSD servers, but we do <br>
not).<br>
<br>
All 4 storage systems are also configured the same way (2 disk groups / <br>
pools / declustered arrays, one managed by  ctrl A, one by ctrl B,  and <br>
8 volumes out of each; makes altogether 2 x 8 x 10 = 160 NSDs).<br>
<br>
<br>
GPFS BS is 8MiB , according to iohistory (mmdiag) we do see clean IO <br>
requests of 16384 disk blocks (i.e. 8192kiB) from GPFS.<br>
<br>
The first question I have - but that is not my main one: I do see, both <br>
in iostat and on the storage systems, that the default IO requests are <br>
about 4MiB, not 8MiB as I'd expect from above settings (max_sectors_kb <br>
is really in terms of kiB, not sectors, cf. <br>
<a href="https://www.kernel.org/doc/Documentation/block/queue-sysfs.txt" rel="noreferrer" target="_blank">https://www.kernel.org/doc/Documentation/block/queue-sysfs.txt</a>).<br>
<br>
But what puzzles me even more: one of the server compiles IOs even <br>
smaller, varying between 3.2MiB and 3.6MiB mostly - both for reads and <br>
writes ... I just cannot see why.<br>
<br>
I have to suspect that this will (in writing to the storage) cause <br>
incomplete stripe writes on our erasure-coded volumes (8+2p)(as long as <br>
the controller is not able to re-coalesce the data properly; and it <br>
seems it cannot do it completely at least)<br>
<br>
<br>
If someone of you has seen that already and/or knows a potential <br>
explanation I'd be glad to learn about.<br>
<br>
<br>
And if some of you wonder: yes, I (was) moved away from IBM and am now <br>
at KIT.<br>
<br>
Many thanks in advance<br>
<br>
Uwe<br>
<br>
<br>
-- <br>
Karlsruhe Institute of Technology (KIT)<br>
Steinbuch Centre for Computing (SCC)<br>
Scientific Data Management (SDM)<br>
<br>
Uwe Falke<br>
<br>
Hermann-von-Helmholtz-Platz 1, Building 442, Room 187<br>
D-76344 Eggenstein-Leopoldshafen<br>
<br>
Tel: +49 721 608 28024<br>
Email: <a href="mailto:uwe.falke@kit.edu" target="_blank">uwe.falke@kit.edu</a><br>
<a href="http://www.scc.kit.edu" rel="noreferrer" target="_blank">www.scc.kit.edu</a><br>
<br>
Registered office:<br>
Kaiserstraße 12, 76131 Karlsruhe, Germany<br>
<br>
KIT – The Research University in the Helmholtz Association<br>
<br>
_______________________________________________<br>
gpfsug-discuss mailing list<br>
gpfsug-discuss at <a href="http://spectrumscale.org" rel="noreferrer" target="_blank">spectrumscale.org</a><br>
<a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" rel="noreferrer" target="_blank">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a><br>
</blockquote></div>