Microsoft Virtualization Discussions
Microsoft Virtualization Discussions
Hi
I have 4 CSV LUN's for Hyper-v Cluster.
Each volume is 500 GB (thin provisioned), with a 250 GB LUN with space reservation.
I used to have snapshots of the LUN in the volume, however they are all deleted. What I don't understand is why the volume reports 81% used spaced when there is only 1 LUN of 250 GB. My logic tells me 250 GB of 500 GB should be 50%. What is taking up space from 50% to 81%?
So when i go to my Hyper-v Node, start snapdrive and try to resize, I can't resize to more than 380 GB.
Seems very strange to me... Maybe it has something to do with this Fractional option...
Any help is very appreciated.
/Regards Martin
What settings have you got on the volumes for the snapshot reserve and the fractional reserve?
Chris
Volume: CSV1
Size: 500GB
Space Setting: None
Fractional Space Reservation: 100%
Deduplication Enabled
LUN: CSV1
Size: 250GB
Space: Reserved
Hi,
This is weird.
Normally Fractional Reserve has no impact when a volume is thinly provisioned (guarantee set to none). What's your ONTAP version?
On 7.3.2 (& before) FR setting on a thinly provisioned volume was always forced to 100% (& couldn't be changed), yet space consumption within volume (with existing snapshots) worked like FR was actually set to 0%.
Now I am on 7.3.4 & can change FR to 0%, but even with old (100%) setting it had no impact whatsoever.
Regards,
Radek
filer1> version
Data ONTAP Release 7.3.2: Thu Oct 15 04:45:30 PDT 2009
Would it help to upgrade to the latest Data OnTAP version?
Please, show output of
df -h CSV1
df -r CSV1
Do you have any snapshots on this volume (snap list csv1)?
Do you have de-duplication enabled for csv1?
filer1> sis status /vol/csv1
filer1> snap list csv1
Volume csv1
working...
No snapshots exist.
OK so de-duplication is enabled for the volume; I think it explains it. First, it works by creating temporary snapshot during dedup run; second, de-duplication by definition cannot predict how much free space will be available, so it could be treated like snapshot w.r.t. to LUN reservation (anyone to comment here?)
You could set fractional reserve to 0 to remove reservation; it is up to you to decide whether you actually want it.
OK, but what is the fractional reserve used for?
I would think that dedupe would save me space, not consume it.
In 7.3.2, you have to set the fractional reserve to 100 before you can set the volume guarantee to none. At this point, the volume is thin provisioned (could be overcommitted), however fully space reserved LUNs inside the volume still follow the same creation rules as in a thick volume (LUN size + fractional reserve can't exceed declared volume size). SInce with the guarantee set to none the volume is already thin provisioned, you could simply overcommit the volume by growing it then grow your LUN. You could also consider removing the space reserve for the LUN.
in 7.3.3, you're not required to set the fractional reserve to 100% before setting the volume guarantee to none. You could always upgrade to 7.3.3 as well.
In short at the volume level consider the frational reserve and the volume guarantee. At the LUN level, consider the LUN space reserve. If you'd like to experiment with the settings, the easy way is via powershell.
http://communities.netapp.com/docs/DOC-6400
http://communities.netapp.com/docs/DOC-6383
J
Well, NetApp has many features; sometimes combining them may have unforeseen consequences.
I just tested in simulator. As soon as A-SIS is enabled for a volume, it reserves space for a LUN in this volume according to fractional_reserve setting. As I believe was already mentioned, to be able to set fractional_reserve=0 and guarantee=none you need 7.3.4.
I can understand why it behaves this way; if you want official answer, open a case with support and ask them to explain this behavior.
Well, to me one thing is still unclear - the fact that the volume guarantee is set to none normally 'disables' fractional reserve, i.e. it should behave like set to 0.
That is not the case here apparently...
Well, I would rather consider it a bug if I wanted to have 100 fractional reserve and it were silently ignored.
Volume guarantee none means I do not want to reserve full volume size upfront. But it does not mean that I do not want to ensure my LUN is still writable – it is just that now this space is reserved from parent aggregate and thus is shared among LUNs from multiple volumes.
If I truly wanted to ignore possible aggregate space overflow, I’d just set fractional_reserve=0 in the first place. That it was not possible was a bug (or, rather, misfeature) that was fixed.
Well, I would rather consider it a bug if I wanted to have 100 fractional reserve and it were silently ignored.
Tricky issue, indeed. I always treated this as a 'handy' bug, because prior to 7.3.3 whenever I set volume guarantee to none, FR was locked at 100% & actually I didn't want FR to be anything else than 0%. But it behaved like 0%, so all was fine for me (although this is very untidy).