FluidFS File-System Metrics
The following tables list the maximum supported configurations.
NOTE: The system does not always prevent you from or warn you about exceeding these numbers.
Table 1. FluidFS System Metrics
Feature
|
Maximum per FluidFS System
|
NAS volumes
|
1024
|
Cloned volumes from a volume
|
1000
|
Files and/or directories
|
10 billion
|
Files in a directory
|
1,000,000
|
Directory depth levels
|
1000
|
Open files (per appliance)
|
250,000 (24-GB appliance) / 800,000 (48-GB appliance)
|
File size
|
128 TB
|
Number of local ACLs
|
180 per file
|
Cloned files from single file
|
1,048,576
|
Minimum file size for file cloning
|
4 KB
|
Minimum file size for data reduction
|
64 KB
|
Snapshot creation and expiration rate
|
Up to 300 per hour*
|
Number of local users
|
1000
|
Number of local groups
|
1000
|
Maximum number of ADS entries per file
|
5000
|
Maximum number of file-access notification policies
|
1024
|
*Snapshot creation and expiration rate
FluidFS supports from 20 to 300 snapshots per hour system-wide (across all NAS Volumes). The supported number of snapshots per hour varies based on the following factors:
- Load on the system. When a snapshot is expired on FluidFS, the background reclaimer process crawls the file system to reclaim space to the NAS pool. If UNMAP is enabled, the process also UNMAPs space on the SAN backend. The reclaimer process is resource-intensive, and if there is a large amount of load on the system, fewer snapshots per hour should be used to prevent the snapshot reclaimer from affecting end users.
- Load on the system from external SMB and NFS clients. If the system is under heavy load to service SMB or NFS clients, it will have less system resources available for snapshot expiry. For systems under heavy load, fewer snapshots per hour should be used.
- Load on the system from FluidFS Replication or NDMP backups. For systems under heavy load due to replication or NDMP backups, fewer snapshots per hour should be used.
- The capabilities of the backend SAN. FluidFS clusters that are using a backend SAN with SSDs can support more snapshots per hour than backend SANs using slower spinning disks.
- Content of the snapshots. When snapshots are expired, the snapshot reclaimer crawls the file system to locate freed blocks. Depending on the content of the snapshots, the reclaimer could take more or less resources to expire them. The resources that the snapshot reclaimer uses to expire snapshots is based on:
- Amount of data that is unique to the snapshot that is being expired. Snapshots that contain a larger total amount of data take more resources to expire.
- The makeup of the data. Snapshots which contain many small files result in a more randomized access pattern and take longer to expire and consume more system resources. Snapshots with large files being reclaimed result in a more sequential access pattern and consume less system resources.
- Potential inode imbalance between file system domains. If there are FluidFS File System Domains which contain a disproportionately larger number of inodes than other File System Domains, the snapshot takes longer to expire, as the reclaimer process could be bottlenecked on one File System Domain.
Table 2. FluidFS NAS Volume Metrics
Feature
|
Maximum per NAS Volume/System
|
NAS volume size
|
Available NAS pool (minimum 20 MB)
|
Snapshots
|
10,000 / 100,000
|
Snapshot schedules
|
1024 / 1024
|
Redirection folders
|
1024 / 1024
|