Hey David,
Hummm. One thing I've noticed is inside the 7-Mode data scheme there are separate tables for qtree and quota. They both have fields for a disk_limit_mb. They are called:
In the qtree table there is a field called: disk_limit_mb
In the quota table there is a field called: hard_disk_limit_mb
I'm not entirely sure why both exist. For a couple of qtrees I'm looking at both fields have the exact same values. I might have thought that the quota table reflected what was in the /etc/quota file and I wouldn't have suspected to see anything like a disk_limit_mb field on the qtree table itself ... since qtrees don't really hold 'quota limit' information, because instead it is really in the /etc/quota file. So my guess is the value in the qtree table is just a copy of that same thing that is in the quota table ... just included b WFA engineers since it is so common for folks to put disk limits on things and it saves writing tricky SQL if it is also just right there in the qtree table.
I suspect the workflow you are looking at (actually, I know 🙂 uses the disk_limit_mb from the qtree table. When you say you changed a quota size on the filer does that mean you edited the /etc/quota file?
Here are some things I would think of to try and look into:
- I wonder if turning quotas off/on on the volume is required for the change to show up
- don't forget to force a OCUM polling update (filer->OCUM), wait a bit, then force a WFA acquire (OCUM->WFA)
- If you can, peek at the data dictionary tables inside WFA to look at both qtree and quota tables
I'll see if I can re-create the problem also.