<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hey<br>
    <br>
      So yes, you're quite right - we have higher order fault tolerant
    cluster wide methods of dealing with such requirements already. 
    However, I still think the end user should be empowered to be able
    construct such methods themselves if needs be.<br>
    <br>
    Yes, the comment is merely an aid [but also useful as a generic
    comment field] and as such could be utilised to encode basic
    metadata into the comment field.<br>
    <br>
    I'll log an RFE and see where we go from here.<br>
    <br>
    Cheers<br>
    <br>
    Jez<br>
    <br>
    <div class="moz-cite-prefix">On 13/09/16 21:51, Yuri L Volobuev
      wrote:<br>
    </div>
    <blockquote
cite="mid:OFE063FADB.FC81FCB8-ON8825802D.00717A9B-8825802D.00728EA8@notes.na.collabserv.com"
      type="cite">
      <p>Hi Jez,<br>
        <br>
        It sounds to me like the functionality that you're _really_
        looking for is an ability to to do automated snapshot
        management, similar to what's available on other storage
        systems. For example, "create a new snapshot of filesets X, Y, Z
        every 30 min, keep the last 16 snapshots". I've seen many
        examples of sysadmins rolling their own snapshot management
        system along those lines, and an ability to add an expiration
        string as a snapshot "comment" appears to be merely an aid in
        keeping such DIY snapshot management scripts a bit simpler --
        not by much though. The end user would still be on the hook for
        some heavy lifting, in particular figuring out a way to run an
        equivalent of a cluster-aware cron with acceptable fault
        tolerance semantics. That is, if a snapshot creation is
        scheduled, only one node in the cluster should attempt to create
        the snapshot, but if that node fails, another node needs to step
        in (as opposed to skipping the scheduled snapshot creation).
        This is doable outside of GPFS, of course, but is not trivial.
        Architecturally, the right place to implement a fault-tolerant
        cluster-aware scheduling framework is GPFS itself, as the most
        complex pieces are already there. We have some plans for work
        along those lines, but if you want to reinforce the point with
        an RFE, that would be fine, too.<br>
        <br>
        yuri<br>
        <br>
        <img src="cid:part1.12A6B029.E43686B5@pixitmedia.com"
          alt="Inactive hide details for Jez Tucker ---09/13/2016
          02:10:31 AM---Hey Yuri, Perhaps an RFE here, but could I
          suggest there is" border="0" height="16" width="16"><font
          color="#424282">Jez Tucker ---09/13/2016 02:10:31 AM---Hey
          Yuri, Perhaps an RFE here, but could I suggest there is much
          value in</font><br>
        <br>
        <font color="#5F5F5F" size="2">From: </font><font size="2">Jez
          Tucker <a class="moz-txt-link-rfc2396E" href="mailto:jtucker@pixitmedia.com"><jtucker@pixitmedia.com></a></font><br>
        <font color="#5F5F5F" size="2">To: </font><font size="2"><a class="moz-txt-link-abbreviated" href="mailto:gpfsug-discuss@spectrumscale.org">gpfsug-discuss@spectrumscale.org</a>,
        </font><br>
        <font color="#5F5F5F" size="2">Date: </font><font size="2">09/13/2016
          02:10 AM</font><br>
        <font color="#5F5F5F" size="2">Subject: </font><font size="2">Re:
          [gpfsug-discuss] gpfs snapshots</font><br>
        <font color="#5F5F5F" size="2">Sent by: </font><font size="2"><a class="moz-txt-link-abbreviated" href="mailto:gpfsug-discuss-bounces@spectrumscale.org">gpfsug-discuss-bounces@spectrumscale.org</a></font><br>
      </p>
      <hr style="color:#8091A5; " align="left" noshade="noshade"
        size="2" width="100%"><br>
      <br>
      <br>
      <font size="4">Hey Yuri,<br>
        <br>
          Perhaps an RFE here, but could I suggest there is much value
        in adding a -c <comment> option to mmcrsnapshot?<br>
        <br>
        Use cases:<br>
        <br>
        mmcrsnapshot myfsname @GMT-2016.09.13-10.00.00 -j myfilesetname
        -c "Before phase 2"<br>
        <br>
        and<br>
        <br>
        mmcrsnapshot myfsname @GMT-2016.09.13-10.00.00 -j myfilesetname
        -c "expire:GMT-2017.04.21-16.00.00"<br>
        <br>
        Ideally also: mmcrsnapshot fs1
        fset1:snapA:expirestr,fset2:snapB:expirestr,fset3:snapC:expirestr<br>
        <br>
        Then it's easy to iterate over snapshots and subsequently
        mmdelsnapshot snaps which are no longer required.<br>
        There are lots of methods to achieve this, but without external
        databases / suchlike, this is rather simple and effective for
        end users.<br>
        <br>
        Alternatively a second comment like -expire flag as user
        metadata may be preferential.<br>
        <br>
        Thoughts?<br>
        <br>
        Jez<br>
        <br>
      </font><br>
      <font size="4">On 13/09/16 05:32, </font><a
        moz-do-not-send="true" href="mailto:Valdis.Kletnieks@vt.edu"><u><font
            color="#0000FF" size="4">Valdis.Kletnieks@vt.edu</font></u></a><font
        size="4"> wrote:</font>
      <ul>
        <ul>
          <tt><font size="4">On Tue, 13 Sep 2016 00:30:19 +0200, Lukas
              Hejtmanek said:<br>
            </font></tt>
          <ul>
            <ul>
              <tt><font size="4">I guess we could reach snapid 100,000.<br>
                </font></tt>
            </ul>
          </ul>
          <tt><font size="4"><br>
              It probably stores the snap ID as a 32 or 64 bit int, so
              100K is peanuts.<br>
              <br>
              What you *do* want to do is make the snap *name*
              meaningful, using<br>
              a timestamp or something to keep your sanity.<br>
              <br>
              mmcrsnapshot fs923 `date +%y%m%d-%H%M`   or similar.<br>
              _______________________________________________<br>
              gpfsug-discuss mailing list<br>
              gpfsug-discuss at spectrumscale.org<br>
            </font></tt><a moz-do-not-send="true"
            href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss"><tt><u><font
                  color="#0000FF" size="4">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</font></u></tt></a><tt><font
              size="4"><br>
            </font></tt>
        </ul>
      </ul>
      <font size="4"><br>
      </font><br>
      <font size="4">-- </font><br>
      <font face="Arial" size="4">Jez Tucker<br>
        Head of Research & Product Development</font><font
        color="#FF0000" face="Arial" size="4"><br>
        Pixit Media</font><u><font color="#0000FF" face="Arial" size="4"><br>
        </font></u><a moz-do-not-send="true"
        href="http://www.pixitmedia.com/"><u><font color="#0000FF"
            face="Arial" size="4">www.pixitmedia.com</font></u></a><br>
      <br>
      <br>
      <font size="4">This email is confidential in that it is intended
        for the exclusive attention of the addressee(s) indicated. If
        you are not the intended recipient, this email should not be
        read or disclosed to any other person. Please notify the sender
        immediately and delete this email from your computer system. Any
        opinions expressed are not necessarily those of the company from
        which this email was sent and, whilst to the best of our
        knowledge no viruses or defects exist, no responsibility can be
        accepted for any loss or damage arising from its receipt or
        subsequent use of this email.</font><tt>_______________________________________________<br>
        gpfsug-discuss mailing list<br>
        gpfsug-discuss at spectrumscale.org<br>
      </tt><tt><a moz-do-not-send="true"
          href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a></tt><tt><br>
      </tt><br>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
<a class="moz-txt-link-freetext" href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a>
</pre>
    </blockquote>
    <br>
    <br>
    <div class="moz-signature">-- <br>
      <div>
        <font color="#000000" face="arial">
          Jez Tucker<br>
          Head of Research & Product Development<br>
          <font color="#FF0000">Pixit Media</font><br>
          Mobile: +44 (0) 776 419 3820<br>
          <a href="http://www.pixitmedia.com">www.pixitmedia.com</a><br>
        </font>
      </div>
    </div>
  </body>
</html>

<br>
<div><img src="http://pixitmedia.com/sig/sig-cio.jpg"></div><div>This email is confidential in that it is intended for the exclusive attention of the addressee(s) indicated. If you are not the intended recipient, this email should not be read or disclosed to any other person. Please notify the sender immediately and delete this email from your computer system. Any opinions expressed are not necessarily those of the company from which this email was sent and, whilst to the best of our knowledge no viruses or defects exist, no responsibility can be accepted for any loss or damage arising from its receipt or subsequent use of this email.</div>