Protection overhead and snapshots are two different things...

one needs to check both, actually

In general, when creating new quotas for existing data,

better have no limits enforced initially.

Wait for the QuotaScan job to finish and check the actual figures.

Then adjust the users' files space consumption and/or the

intended limits to avoid collision, and finally set and enforce the limits.

hth

-- Peter

Hi se_idaho,

there is a setting which sets the hardlimit of the quota also for "protection overhead" - so if you have snapshots for this particular folder you may have to wait until it is out of the snapshots.

check the setting with (7.0.2 specific, may be vary on your code) isi quota quotas view /path/to/quota

you will see if "Snapshots" is set to yes

you will see if "Tresholds Include Overhead" is set to yes

you will see if the quota is exceeded or not

Another test would be to unquote the folder and test if it works - if it does not you may have an permission problem.

Also do an isi quota view instead of an isi quota list.

This will show you if the user exceeded a soft quota for a pre-determined time.

Thanks all for your responses.  They each gave me some good info.

However, in this particular situation we found when a user goes beyond the grace period on a soft limit, the limit actually becomes a hard limit.  Found it even in the documentation.  We had to revert back to an advisory limit.

I submitted a ticket for a bad implementation of the soft limit. 

How do you want soft limits to be implemented instead?

Not in my experiences.  A soft quota is used to warn users that they are approaching a hard limit, not to act as a hard limit.  EMC's implementation would suggest you don't use the hard limit setting and use the soft limit setting as both, if you want to user notifications.  The word soft should mean soft; basically a buffer.  Hard means hard; you go over it, you're stopped.  Anyway, that is how they have always worked in any other system I have been around.

Now, I'm not saying they are wrong; I just don't agree with their implementation....

What you describe is what advisory quotas have been made for, as a third type of quotas.

Soft quotas on Isilon work, as Ed has pointed out, exactly as with any UNIX-based system (Linux, *BSD) in the world.

The funny thing, I too DO suggest an improvement to Isilon regarding soft quotas:

In case of directory "containers" df SHOULD reports the SOFT limit as volume size. Because this soft limit, which gets "hard" after the grace period, is what the users should be aware of in the first place.

For example: 10TB hard, 9 TB soft limits on a directory container. Users will always see size=10TB with df, and become annoyed when running into trouble after reaching only 90% and exceeding the grace period (despite e-mail notifications).

Better: report 9TB as volume size, then allow and report usage >100% during the grace period. This allows for safe planning base on df figures; and reading a usage of >100% already implies an "exceptional" situation.

Open for discussion... if convinced, why not considering an RFE to Isilon.

Cheers

-- Peter

Peter, you do have an interesting suggestion and I've complained to Engineering management too about the lack of visibility of the quotas from clients.   There's nothing more annoying to a user who is denied a write but can't tell why.

Your suggestion isn't without pitfalls though.  Should a volume be 110% full?  Aren't some client reporting tools going to get confused because of this?  Say today my disk is 110% full but I can still write because I'm over my soft quota but within the grace period.  Tomorrow my disk is 100% full and I can't write.  As a user, I might want to complain that you "shrunk" my disk and caused my jobs to fail.  I delete a half terabyte of data and the disk is still full!  Brings back bad memories of the NetApp implementation of snapshots...

Thanks Ed, to my experience time-dependant behavior always

has potential for confusion, and will here it will apply to both types of soft quotas.

Same is true for snapshot space consumption.

So the question left  is how will users and applications deal with a reported usage of >100%.

For human users, I find it easier to communicate that 100% are always

guaranteed available, and that they are allowed to overshoot by another X% for Y days,

rather than stating that 100% is the "volume size" BUT there is a "danger zone"

starting already at 100-X% where one will get blocked after Y days.

For automated workflows that might get confused at >100%, yeah, that

behavior should be configurable of course (like virtual hot spares options).

In many other technical systems various means exist to allow

certain metrics to actually reach a 100% limit but in a graceful way:

degrading speed, or by visual or audible cues at increasing intensities.

Wouldn't these approaches be cool for file system quotas?

Sure, but probably only on April 1st. 

-- Peter