You could put snapshot data in a separate storage pool. Then it should be visible how much space it occupies, but it’s a bit hard to see how this will be usable/manageable..<br><br><br> -jf<br><div class="gmail_quote"><div dir="ltr">tir. 29. jan. 2019 kl. 20:08 skrev Christopher Black <<a href="mailto:cblack@nygenome.org">cblack@nygenome.org</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="m_5589713380150368241WordSection1">
<p class="MsoNormal">Thanks for the quick and detailed reply! I had read the manual and was aware of the warnings about -d (mentioned in my PS).<u></u><u></u></p>
<p class="MsoNormal">On systems with high churn (lots of temporary files, lots of big and small deletes along with many new files), I’ve previously used estimates of snapshot size as a useful signal on whether we can expect to see an increase in available space
over the next few days as snapshots expire. I’ve used this technique on a few different more mainstream storage systems, but never on gpfs.<u></u><u></u></p>
<p class="MsoNormal">I’d find it useful to have a similar way to monitor “space to be freed pending snapshot deletes” on gpfs. It sounds like there is not an existing solution for this so it would be a request for enhancement.<u></u><u></u></p>
<p class="MsoNormal">I’m not sure how much overhead there would be keeping a running counter for blocks changed since snapshot creation or if that would completely fall apart on large systems or systems with many snapshots. If that is a consideration even having
only an estimate for the oldest snapshot would be useful, but I realize that can depend on all the other later snapshots as well. Perhaps an overall “size of all snapshots” would be easier to manage and would still be useful to us.<u></u><u></u></p>
<p class="MsoNormal">I don’t need this number to be 100% accurate, but a low or floor estimate would be very useful.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Is anyone else interested in this? Do other people have other ways to estimate how much space they will get back as snapshots expire? Is there a more efficient way of making such an estimate available to admins other than running an mmlssnapshot
-d every night and recording the output?<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Thanks all!<u></u><u></u></p>
<p class="MsoNormal">Chris<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black"><<a href="mailto:gpfsug-discuss-bounces@spectrumscale.org" target="_blank">gpfsug-discuss-bounces@spectrumscale.org</a>> on behalf of Marc A Kaplan <<a href="mailto:makaplan@us.ibm.com" target="_blank">makaplan@us.ibm.com</a>><br>
<b>Reply-To: </b>gpfsug main discussion list <<a href="mailto:gpfsug-discuss@spectrumscale.org" target="_blank">gpfsug-discuss@spectrumscale.org</a>><br>
<b>Date: </b>Tuesday, January 29, 2019 at 1:24 PM<br>
<b>To: </b>gpfsug main discussion list <<a href="mailto:gpfsug-discuss@spectrumscale.org" target="_blank">gpfsug-discuss@spectrumscale.org</a>><br>
<b>Subject: </b>Re: [gpfsug-discuss] Querying size of snapshots<u></u><u></u></span></p>
</div></div></div><div lang="EN-US" link="#0563C1" vlink="#954F72"><div class="m_5589713380150368241WordSection1">
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">1. First off, let's RTFM ...</span><br>
<br>
<b>-d </b>Displays the amount of storage that is used by the snapshot.<br>
This operation requires an amount of time that is proportional to the size of the file system; therefore,<br>
it can take several minutes or even hours on a large and heavily-loaded file system.<br>
This optional parameter can impact overall system performance. Avoid running the <b>
mmlssnapshot</b><br>
command with this parameter frequently or during periods of high file system activity.<span style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>
</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">SOOOO.. there's that. </span><br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">2. Next you may ask, HOW is that?</span><br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Snapshots are maintained with a "COW" strategy -- They are created quickly, essentially just making a record that the snapshot was created and at such and such time -- when the snapshot is the same
as the "live" filesystem...</span><br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Then over time, each change to a block of data in live system requires that a copy is made of the old data block and that is associated with the most recently created snapshot.... SO, as more and
more changes are made to different blocks over time the snapshot becomes bigger and bigger. How big? Well it seems the current implementation does not keep a "simple counter" of the number of blocks -- but rather, a list of the blocks that were COW'ed....
So when you come and ask "How big"... GPFS has to go traverse the file sytem metadata and count those COW'ed blocks....</span><br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">3. So why not keep a counter? Well, it's likely not so simple. For starters GPFS is typically running concurrently on several or many nodes... And probably was not deemed worth the effort .....
IF a convincing case could be made, I'd bet there is a way... to at least keep approximate numbers, log records, exact updates periodically, etc, etc -- similar to the way space allocation and accounting is done for the live file system...</span><br>
<br>
<br>
<u></u><u></u></p>
</div>
<hr>
<div style="font-size:7.5pt;font-family:arial;font-style:normal;font-weight:normal">
This message is for the recipient’s use only, and may contain confidential, privileged or protected information. Any unauthorized use or dissemination of this communication is prohibited. If you received this message in error, please immediately notify the
sender and destroy all copies of this message. The recipient should check this email and any attachments for the presence of viruses, as we accept no liability for any damage caused by any virus transmitted by this email.</div>
</div>
_______________________________________________<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>