<span style=" font-size:10pt;font-family:sans-serif">1. First off, let's
RTFM ...</span><br><br><span style=" font-size:10pt;font-family:}"><b>-d </b>Displays the
amount of storage that is used by the snapshot.</span><br><span style=" font-size:10pt;font-family:}">This operation requires
an amount of time that is proportional to the size of the file system;
therefore,</span><br><span style=" font-size:10pt;font-family:}">it can take several minutes
or even hours on a large and heavily-loaded file system.</span><br><span style=" font-size:10pt;font-family:}">This optional parameter
can impact overall system performance. Avoid running the <b>mmlssnapshot</b></span><br><span style=" font-size:10pt;font-family:}">command with this parameter
frequently or during periods of high file system activity.</span><span style=" font-size:10pt;font-family:sans-serif"><br></span><br><span style=" font-size:10pt;font-family:sans-serif">SOOOO.. there's
that. </span><br><br><span style=" font-size:10pt;font-family:sans-serif">2. Next you may
ask, HOW is that?</span><br><br><span style=" font-size:10pt;font-family: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:10pt;font-family: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:10pt;font-family: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>