[gpfsug-discuss] gpfs snapshots
Jez Tucker
jtucker at pixitmedia.com
Tue Sep 13 23:28:22 BST 2016
Hey
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.
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.
I'll log an RFE and see where we go from here.
Cheers
Jez
On 13/09/16 21:51, Yuri L Volobuev wrote:
>
> 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
>
> Inactive hide details for Jez Tucker ---09/13/2016 02:10:31 AM---Hey
> Yuri, Perhaps an RFE here, but could I suggest there isJez Tucker
> ---09/13/2016 02:10:31 AM---Hey Yuri, Perhaps an RFE here, but could I
> suggest there is much value in
>
> 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_
> <mailto: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_ <http://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
>
>
>
>
> _______________________________________________
> 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
Mobile: +44 (0) 776 419 3820
www.pixitmedia.com <http://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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20160913/696599a6/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20160913/696599a6/attachment.gif>
More information about the gpfsug-discuss
mailing list