For rough calculations this is more like RAID 5.  Even though you get 2 disks worth of data protection, it is done by using a layout trick so that no additional overhead is required in most situations.  So 1 node's worth of storage is being pulled out of your 6 node cluster.  You can look at this as 1/6 which is 16% of the total cluster is overhead or as a 1 node of overhead / 5 nodes of storage which gives you 20% overhead.  Both calculations are correct and say slightly different things.  Let's assume for simplicity sake you have 6 x 100 TB nodes for a total raw capacity of 600 TB.  Your usable space would be roughly 500 TB.  600TB * .16666 = 100 TB of overhead  At small node counts both numbers are easy to calculate using approximations.  Things get more complicated when you exceed 16 nodes.  The overhead stays fixed after a certain point due to the maximum number of nodes we will stripe data across (16) and the number of parity stripes required (anywhere from 1 to 4).
hello,   we are doing netapp to isilon migration using isi_vol_copy, we noticed very strange thing related to size. initially we bought isilon with sizes that matches / little more than netapp so once we started migration isilon is consuming lot more space than we anticipated.  here i picked one volume on netapp ( its not a flex clone , original volume ) which is 55gb ( attached the screen shot ). once we do isi_vol_copy we noticed the size on isilon its taking 263gb ( attached the screen shot ) also we verified the data on both its same even application team verified after migration they are good and they matched the data as well. which includes the data-protection overhead still its way way  high.  curios , is netapp has dedup feature ? which isilon didn't.  bec this is my qa volume which has prod / staging / test ..   if this the case then our storage sizing is not right.
Netapp - Isilon volume migration : volume sizes mismatch