[gpfsug-discuss] Querying size of snapshots

Marc A Kaplan makaplan at us.ibm.com
Tue Jan 29 18:24:17 GMT 2019


1. First off, let's RTFM ...

-d Displays the amount of storage that is used by the snapshot.
This operation requires an amount of time that is proportional to the size 
of the file system; therefore,
it can take several minutes or even hours on a large and heavily-loaded 
file system.
This optional parameter can impact overall system performance. Avoid 
running the mmlssnapshot
command with this parameter frequently or during periods of high file 
system activity.

SOOOO.. there's that. 

2. Next you may ask, HOW is that?

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...

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....

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...


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20190129/b7a5e327/attachment-0002.htm>


More information about the gpfsug-discuss mailing list