I wrote:

[...] the block allocation map (4 bytes per 4K block on the data discs)

[...]

The former, in particular, does not have its blocks deallocated just because they have reverted to being all-zero.

It occurs to me that one thing that causes the allocation map to expand to its maximum size rapidly in a new volume is taking a snapshot.

And *that* reminds me about one of the promises about ONTAP 6.0 in Field Alert #66:

| * Enhanced Snapshot functionality to provide near instantaneous | snapshot creation/deletion and increased snapshot count from 20 | to 31 per volume

The main reason taking a snapshot is not "nearly instantantaneous" at the moment is that the block allocation map gets completely rewritten. (And as a result, there's a space overhead of the size of the map times the number of snapshots less one.)

It would be interesting to know how NetApp have reworked the internal structures to get round this. But maybe it's Confidential Information and we'll have our lips stapled together if we start speculating... :-)

The maximum of 31 snapshots suggests that the basic style of a 32-bit word of allocation information per block still persists.

Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QG, Phone: +44 1223 334715 United Kingdom.