In OneFS 8.2, SmartQuotas now has four principle resources used in quota accounting:

Accounting Resource


Physical Size

This includes all the on-disk storage associated with files and directories, with the exception of some metadata objects including the LIN tree, snapshot tracking files (STFs). For deduplicated data and file clones, each file’s 8KB reference to a shadow store is included in the physical space calculation.

File system logical size

File system logical size calculation approximates disk usage on ‘typical’ storage arrays by ignoring the erasure code, or FEC, protection overhead that OneFS employs. For regular files, the logical data space is the amount of storage required to house a particular file if it was 1x mirrored. Logical space also incorporates a file’s metadata resources.

Application Logical Size

Reports total logical data store across different tiers, including CloudPools. This allows users to view quotas and free space as an application would view it, in terms of how much capacity is available to store logical data regardless of data reduction or tiering technology.


SmartQuotas counts the number of logical inodes, which allows accounting for files without any ambiguity from hard links or protection.


When configuring a quota, these are accounting options are available as enforcement limits. For example, from the OneFS WebUI:



Application logical size quotas are introduced in OneFS 8.2, allowing users to view quotas and free space as an application sees it – regardless of data reduction, stubbing, sparse blocks, etc.

Existing quotas can easily be configured to use application logical size upon upgrading to 8.2. The benefits of application logical size quotas include:

  • Snapshots, protection overhead, dedupe, compression, and location of files all have no effect on quota consumption
  • Removes previous limitation where SmartQuotas only reported on-cluster storage, ignoring cloud consumption
  • Presents view that aligns with Windows storage accounting
  • Enables accounting and enforcing quota on actual file sizes
  • Precisely accounts for small files
  • Enables enforcing quotas on a path irrespective of the physical location of file.

The following table describes how SmartQuotas accounts for a 1KB file with the various data types:


Data Type


File: physical size

Every non-sparse 8KB disk block a file consumes including protection

File: file system logical size

Every non-sparse 8KB disk block a file consumes excluding protection

File: application logical size

Actual size of file (rather than total of 8KB disk blocks consumed)

CloudPools file: file system logical size

Size of CloudPools SmartLink stub file (8KB)

CloudPools file: application logical size

Actual size of file on cloud storage (rather than local stub file)


Sum of all directory entries


Data size

ACL and similar

Data size

Alternate data stream

Each ADS is charged as a file and a container as a directory


The following example shows each method of accounting for a 1KB file:



Logical size reports 8KB, or one block, physical size reports 24KB (file with 3x mirroring protection), and application logical shows its actual size of 1KB.

Quotas with application logical accounting can easily be created from either the OneFS WebUI or CLI. For example, the following syntax will configure an applogical hard quota with a 5GB threshold on the /ifs/data directory:

# isi quota quotas create -path=/ifs/data directory --thresholdson=applogicalsize --hard-threshold=5G

Other resources encountered during quota accounting include:

Hard Links - Each logical inode is accounted exactly once in every domain to which it belongs. If an inode is present in multiple domains, it is accounted in multiple domains. Alternatives such as shared accounting were considered. However, if inodes are not accounted once in every domain, it is possible for the deletion of a hard link in one domain to put another domain over quota.

Alternate Data Streams (ADS) - A file with an alternate data stream or resource fork is accounted as the sum of the resource usage of the individual file, the usage for the container directory and the usage for each ADS. SmartQuotas handles the rename of a file with ADS synchronously, despite the fact that the ADS container is just a directory. SmartQuotas will store an accounting summary on the ADS container to handle renames.

Directory Rename – A directory rename presents a unique challenge to a per-directory quota system. Renames of directories within a domain are trivial - if both the source and target directories have the same domain membership, no accounting changes. However, non-empty directories are not permitted to be moved when the SmartQuotas configuration is different on the source and the target parent directories. If a user trusts the client operating systems to copy files and preserve all the necessary attributes, then the user may set dir_rename_errno to EXDEV, which causes most Unix and Windows clients to do a copy and delete of the directory tree to affect the move.

Snapshot Accounting – If desired, a quota domain can also include snapshot usage in its accounting. SmartQuotas will only support snapshots created after the quota domain was created. This is because determining quota governance (including QuotaScan job) for existing snapshots is a very time and resource consuming operation. As most administrators cycle their snapshots through timed expirations, SmartQuotas will eventually accrue enough accounting information to include the entire set of relevant snapshots on the system.