I'm realizing that I spoke inaccurately below ... here's my effort to clean up my errors (without, I'm hoping, introducing new ones):
-Keeping ~20% free on a heavily used aggregate makes sense /operationally/ ... the applications are likely to want space, and running out of space is generally detrimental to application behavior. But there is no particular /WAFL/ requirement for this.
-WAFL's de-dupe process wants a few percent free (~4%), in order to give itself working space
-WAFL's write performance can benefit from contiguous free blocks ... but WAFL reserves ~10% of an aggregate's space on creation for various functions, including this one. So filling up the user-accessible portion of the volume doesn't necessarily impact the contiguous free block situation.
-And yes, with V-Series, ONTAP no longer has visibility into physical block layout, so this discussion becomes moot.
hth,
--sk
On 3/15/2012 11:46 AM, Stuart Kendrick wrote:
Hi folks,
I'm familiar with the NetApp recommendation to keep ~20% free on all volumes ... this allows WAFL to maximize its performance (convert random IO to streaming IO ... i.e. the 'Write Anywhere ...' part of WAFL).
But I'm skeptical that this recommendation applies to V-Series installations, i.e. situations in which the backend array was built by someone other than NetApp.
Seems to me that with V-Series, WAFL may find what it thinks are 128K of contiguous blocks on storage and perform the WRITE ... but ... since the backend array has virtualized the blocks in some fashion, opaque to ONTAP, there is no knowing what really happens. In other words, the blocks which ONTAP specifies do /not/ map to physical blocks ... once the WRITE arrives at the array, the backend will do whatever it thinks best with them, perhaps perform a streaming write to contiguous blocks, perhaps not. Implementation-specific.
-In fact, with a V-Series, I would imagine (I have a rich imagination) that ONTAP doesn't bother to even try to convert random IO into streaming IO -- I would imagine that it just hands the blocks to the backend in a jumble and says "Do whatever".
So, I would like to claim that with V-Series, I can fill up my volumes without impacting write performance ... or, more precisely, that impact is dependent on the characteristics of the backend ... perhaps the backend needs free space in order to optimize its write performance, perhaps it does not. [In our particular case, we're using 3Par, and 'fullness' would not impact performance.]
Would anyone see holes in my thinking?
--sk
Stuart Kendrick FHCRC