File System and Project Settings
The simplest way of enforcing quotas and reservations is on a per-project or per-filesystem
basis. Quotas and reservations do not apply to LUNs, though their usage is accounted for in the
total project quota or reservations.
Data Quotas
A data quota enforces a limit on the amount of space a filesystem or project can use. By
default, it will include the data in the filesystem and all snapshots. Clients attempting to write
new data will get an error when the filesystem is full, either because of a quota or because the
storage pool is out of space. As described in the snapshot section, this behavior may not be intuitive in
all situations, particularly when snapshots are present. Removing a file may cause the filesystem to
write new data if the data blocks are referenced by a snapshot, so it may be the case that the only
way to decrease space usage is to destroy existing snapshots.
If the 'include snapshots' property is unset, then the quota applies only to the immediate
data referenced by the filesystem, not any snapshots. The space used by snapshots is enforced by the
project-level quota but is otherwise not enforced. In this situation, removing a file referenced by
a snapshot will cause the filesystem's referenced data to decrease, even though the system as a
whole is using more space. If the storage pool is full (as opposed to the filesystem reaching a
preset quota), then the only way to free up space may be to destroy snapshots.
Data quotas are strictly enforced, which means that as space usage nears the limit, the amount
of data that can be written must be throttled as the precise amount of data to be written is not
known until after writes have been acknowledged. This can affect performance when operating at or
near the quota. Because of this, it is generally advisable to remain below the quota during normal
operating procedures.
Quotas are managed through the BUI under Shares -> General -> Space Usage -> Data.
They are managed in the CLI as the quota and quota_snap
properties.
Data Reservations
A data reservation is used to make sure that a filesystem or project has at least a certain
amount of available space, even if other shares in the system try to use more space. This unused
reservation is considered part of the filesystem, so if the rest of the pool (or project) reaches
capacity, the filesystem can still write new data even though other shares may be out of space.
By default, a reservation includes all snapshots of a filesystem. If the 'include snapshots'
property is unset, then the reservation only applies to the immediate data of the filesystem. As
described in the snapshot
section, the behavior when taking snapshots may not always be intuitive. If a reservation on
filesystem data (but not snapshots) is in effect, then whenever a snapshot is taken, the system must
reserve enough space for that snapshot to diverge completely, even if that never occurs. For
example, if a 50G filesystem has a 100G reservation without snapshots, then taking the first
snapshot will reserve an additional 50G of space, and the filesystem will end up reserving 150G of
space total. If there is insufficient space to guarantee complete divergence of data, then taking
the snapshot will fail.
Reservations are managed through the BUI under Shares -> General -> Space Usage ->
Data. They are managed in the CLI as the reservation and
reservation_snap properties.
Space Management for Replicating LUNs
When you create a LUN the full physical space you configure for the LUN is reserved and cannot
be used by other file systems (unless it is thinly provisioned). For replication, when you take a
snapshot of a LUN of any given size, up to twice the size of the LUN is also reserved, depending on
how much of the LUN space has been used.
The following list shows the maximum overhead space required when replicating a LUN:
