[gpfsug-discuss] gpfs snapshots

[Yuri L Volobuev]

Hi Jez,

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.

yuri



From:	Jez Tucker <jtucker at pixitmedia.com>
To:	gpfsug-discuss at spectrumscale.org,
Date:	09/13/2016 02:10 AM
Subject:	Re: [gpfsug-discuss] gpfs snapshots
Sent by:	gpfsug-discuss-bounces at spectrumscale.org



Hey Yuri,

  Perhaps an RFE here, but could I suggest there is much value in adding a
-c <comment> option to mmcrsnapshot?

Use cases:

mmcrsnapshot myfsname @GMT-2016.09.13-10.00.00 -j myfilesetname -c "Before
phase 2"

and

mmcrsnapshot myfsname @GMT-2016.09.13-10.00.00 -j myfilesetname -c
"expire:GMT-2017.04.21-16.00.00"

Ideally also: mmcrsnapshot fs1
fset1:snapA:expirestr,fset2:snapB:expirestr,fset3:snapC:expirestr

Then it's easy to iterate over snapshots and subsequently mmdelsnapshot
snaps which are no longer required.
There are lots of methods to achieve this, but without external databases /
suchlike, this is rather simple and effective for end users.

Alternatively a second comment like -expire flag as user metadata may be
preferential.

Thoughts?

Jez


On 13/09/16 05:32, Valdis.Kletnieks at vt.edu wrote:
      On Tue, 13 Sep 2016 00:30:19 +0200, Lukas Hejtmanek said:

            I guess we could reach snapid 100,000.


      It probably stores the snap ID as a 32 or 64 bit int, so 100K is
      peanuts.

      What you *do* want to do is make the snap *name* meaningful, using
      a timestamp or something to keep your sanity.

      mmcrsnapshot fs923 `date +%y%m%d-%H%M`   or similar.
      _______________________________________________
      gpfsug-discuss mailing list
      gpfsug-discuss at spectrumscale.org
      http://gpfsug.org/mailman/listinfo/gpfsug-discuss



--
Jez Tucker
Head of Research & Product Development
Pixit Media
www.pixitmedia.com


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._______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20160913/1de2cb99/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20160913/1de2cb99/attachment.gif>