Table of Contents
Advertisement
User and group quotas are implemented using delayed enforcement. This means that users
■
will be able to exceed their quota for a short period of time before data is written to disk.
Once the data has been pushed to disk, the user will receive an error on new writes, just as
with the filesystem-level quota case.
User and group quotas are always enforced against referenced data. This means that
■
snapshots do not affect any quotas, and a clone of a snapshot will consume the same amount
of effective quota, even though the underlying blocks are shared.
User and group reservations are not supported.
■
User and group quotas, unlike data quotas, are stored with the regular filesystem data. This
■
means that if the filesystem is out of space, you will not be able to make changes to user
and group quotas. You must first make additional space available before modifying user and
group quotas.
User and group quotas are sent as part of any remote replication. It is up to the administrator
■
to ensure that the name service environments are identical on the source and destination.
NDMP backup and restore of an entire share will include any user or group quotas. Restores
■
into an existing share will not affect any current quotas.
Working with Identity Management
User and group quotas leverage the identity mapping service on the appliance. This allows
users and groups to be specified as either UNIX or Windows identities, depending on the
environment. Like file ownership, these identities are tracked in the following ways:
If there is no UNIX mapping, a reference to the windows ID is stored.
■
If there is a UNIX mapping, then the UNIX ID is stored.
■
This means that the canonical form of the identity is the UNIX ID. If the mapping is changed
later, the new mapping will be enforced based on the new UNIX ID. If a file is created by a
Windows user when no mapping exists, and a mapping is later created, new files will be treated
as a different owner for the purposes of access control and usage format. This also implies that
if a user ID is reused (i.e. a new user name association created), then any existing files or quotas
will appear to be owned by the new user name.
It is recommended that any identity mapping rules be established before attempting to actively
use filesystems. Otherwise, any change in mapping can sometimes have surprising results.
Working with Filesystem Namespace
Every filesystem on the appliance must be given a unique mountpoint which serves as the
access point for the filesystem data. Projects can be given mountpoints, but these serve only as
Working with Identity Management
Shares and Projects
399
Advertisement
Table of Contents
