<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">And use QoS <div><br></div><div>Less aggressive during peak, more on valleys. If your workload allows it. <br><br><div dir="ltr" id="AppleMailSignature"><div>—</div><div>SENT FROM MOBILE DEVICE</div><div>Ystävällisin terveisin / Kind regards / Saludos cordiales / Salutations</div><div>Luis Bolinches</div><div>Consultant IT Specialist</div><div>Mobile Phone: +358503112585</div><div><a href="https://www.youracclaim.com/user/luis-bolinches">https://www.youracclaim.com/user/luis-bolinches</a></div><div><br></div><div>"If you always give you will always have" -- Anonymous</div></div><div dir="ltr"><br>On 18 Oct 2018, at 19.13, Alex Chekholko <<a href="mailto:alex@calicolabs.com">alex@calicolabs.com</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><div dir="ltr">The re-striping uses a lot of I/O, so if your goal is user-facing performance, the re-striping is definitely hurting in the short term and is of questionable value in the long term, depending on how much churn there is on your filesystem.<div><br></div><div>One way to split the difference would be to run your 'mmrestripe -b' midnight to 6am for many days; so it does not conflict with your snapshot. Or whatever other time you have lower user load.</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Oct 18, 2018 at 8:32 AM Peter Childs <<a href="mailto:p.childs@qmul.ac.uk">p.childs@qmul.ac.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We've just added 9 raid volumes to our main storage, (5 Raid6 arrays<br>for data and 4 Raid1 arrays for metadata)<br><br>We are now attempting to rebalance and our data around all the volumes.<br><br>We started with the meta-data doing a "mmrestripe -r" as we'd changed<br>the failure groups to on our meta-data disks and wanted to ensure we<br>had all our metadata on known good ssd. No issues, here we could take<br>snapshots and I even tested it. (New SSD on new failure group and move<br>all old SSD to the same failure group)<br><br>We're now doing a "mmrestripe -b" to rebalance the data accross all 21<br>Volumes however when we attempt to take a snapshot, as we do every<br>night at 11pm it fails with <br><br>sudo /usr/lpp/mmfs/bin/mmcrsnapshot home test<br>Flushing dirty data for snapshot :test...<br>Quiescing all file system operations.<br>Unable to quiesce all nodes; some processes are busy or holding<br>required resources.<br>mmcrsnapshot: Command failed. Examine previous error messages to<br>determine cause.<br><br>Are you meant to be able to take snapshots while re-striping or not? <br><br>I know a rebalance of the data is probably unnecessary, but we'd like<br>to get the best possible speed out of the system, and we also kind of<br>like balance.<br><br>Thanks<br><br><br>-- <br>Peter Childs<br>ITS Research Storage<br>Queen Mary, University of London<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></div></blockquote></div><BR>
Ellei edellä ole toisin mainittu: / Unless stated otherwise above:<BR>
Oy IBM Finland Ab<BR>
PL 265, 00101 Helsinki, Finland<BR>
Business ID, Y-tunnus: 0195876-3 <BR>
Registered in Finland<BR>
<BR>
</body></html>