Inherited Properties
Inherited properties are properties that inherit their value from their parent. Projects can inherit properties from their parent pool, and shares can inherit properties from their parent project. Usually, properties that can be inherited can alternatively be set explicitly on a project or share. When a value is explicitly set for a property that was initially inherited, that property is then a local property.
The BUI only allows the properties to be inherited all at once, while the CLI allows for individual properties to be inherited.
By default, shares inherit all of their properties from their parent project. If a property is changed on a project, all shares that inherit that property (that property has not been set locally) are updated to reflect the new value. When inherited, all properties have the same value as the parent project, with the exception of the mountpoint and SMB properties. When inherited, the mountpoint and SMB properties concatenate the project setting with their own share name.
In addition to the properties described in the following sections, encryption properties also are inherited. If a pool is encrypted, all projects created under that pool inherit the pool’s encryption settings. If a project is encrypted, all shares created under that project inherit the project’s encryption settings. See Encryption Properties. Creating an Encrypted Project - BUI, CLI, and Creating an Encrypted Filesystem or LUN - BUI, CLI.
For a description of how inherited property settings could be changed by restoration from backup, and how to avoid that, see Inherited Property Settings after Restoration from Backup.
Mountpoint
The mountpoint property is the location where the filesystem is mounted. This property is only valid for filesystems.
The following restrictions apply to the mountpoint property:
-
Must be under /export
-
Cannot conflict with another share
-
Cannot conflict with another share on cluster peer to allow for proper failover
When inheriting the mountpoint property, the current dataset name is appended to the project's mountpoint setting, joined with a forward slash (/). For example, if the home project has the mountpoint setting /export/home, then home/chris would inherit the mountpoint /export/home/chris.
SMB shares are exported via their resource name, and the mountpoint is not visible over the protocol. However, even SMB-only shares must have a valid unique mountpoint on the appliance.
Mountpoints can be nested underneath other shares’ mountpoints, although this has some limitations. For more information, see Working with Filesystem Namespace.
Read Only
The read-only property controls whether the filesystem contents are read only. This property is only valid for filesystems.
The contents of a read-only filesystem cannot be modified, regardless of any protocol settings. This setting does not affect the ability to rename, destroy, or change properties of the filesystem. In addition, when a filesystem is read only, access control properties cannot be altered, because they require modifying the attributes of the root directory of the filesystem.
Update Access Time on Read
The update access time on read property controls whether the access time for files is updated on read. This property is only valid for filesystems.
POSIX standards require that the access time for a file properly reflect the last time it was read. This requires issuing writes to the underlying filesystem even for a mostly read-only workload. For working sets consisting primarily of reads over a large number of files, turning off this property may yield performance improvements at the expense of standards conformance. These updates happen asynchronously and are grouped together, so its effect should not be visible except under heavy load.
Non-Blocking Mandatory Locking
The non-blocking mandatory locking property controls whether SMB locking semantics are enforced over POSIX semantics. This property is only valid for filesystems.
By default, filesystems implement file behavior according to POSIX standards. These standards are fundamentally incompatible with the behavior required by the SMB protocol. For shares where the primary protocol is SMB, this option should always be enabled. Changing this property requires all clients to be disconnected and reconnect.
Data Deduplication
The data deduplication property controls whether duplicate copies of data are eliminated. Deduplication is synchronous, pool-wide, block-based, and can be enabled on a per project or share basis.
Before deduplication can be enabled on a project or share, configure the storage pool with meta devices. Meta devices are designated cache devices used to store specific types of metadata to optimize use cases like deduplication.
Deduplication is also only available on datasets with a record size 128K or above.
To enable deduplication, select the Data Deduplication checkbox on the general properties screen for projects or shares. The size of the deduplicated data, as well as the deduplication ratio, will appear in the usage area of the Status Dashboard. Data written with deduplication enabled is entered into the deduplication table indexed by the data checksum. Deduplication forces the use of the cryptographically strong SHA-256 checksum. Subsequent writes will identify duplicate data and retain only the existing copy on disk. Deduplication can only happen between blocks of the same size, data written with the same record size. For best results, set the record size to that of the application using the data; for streaming workloads, use a large record size.
Note:
Starting with the Data Deduplication deferred update in OS8.7, if replication is configured for a deduplicated project or share, a compatibility test will run to determine if the replication target has the required software and meta device for receiving deduplicated updates. If the target is running OS8.6 or earlier, replication updates with deduplication enabled will fail, and an alert will post indicating that data deduplication needs to be disabled at the source. If the target is running OS8.7, but does not have the required meta device, the target will ignore the incoming data deduplication property, and an alert will post to show that the target system will deliberately ignore the deduplication settings during replication receive. If a OS8.6 or earlier source has been replicating to a target with deduplication enabled, the compatibility test will check the target for a meta device or deduplicated share in the package. If the compatibility test finds either of these, the target will preserve the deduplication settings when receiving replication updates.If your data does not contain any duplicates, enabling data deduplication will add overhead (a more CPU-intensive checksum and on-disk deduplication table entries) without providing any benefit. If your data does contain duplicates, enabling data deduplication will both save space by storing only one copy of a given block regardless of how many times it occurs. Deduplication could impact performance in that the checksum is more expensive to compute and the metadata of the deduplication table must be accessed and maintained.
Note that deduplication has no effect on the calculated size of a share and does not affect the amount of space used for the pool. For example, if two shares contain the same 512 GB file, each will appear to be 512 GB in size, but the total for the pool will be just 512 GB, and deduplication will be reported as 512G (2x). If three shares contain the same 512 GB file, each appears as 512 GB in size, the total for the pool will be 512 GB, and deduplication will be 1024G (3x).
There are 3 sets of analytics used to monitor performance of deduplication:
-
ZFS DMU operations (by DMU object type) - This analytic will show you how many operations are being performed against the Data Deduplication Table compared to other ZFS operations.
-
Meta device bytes used (by pool) - Amount of space used on the metadata devices.
This statistic will remain blank until at least 1% of the meta device capacity is used.
-
Meta device percent used (by pool) - Percent of space used on the metadata devices.
This statistic will remain blank until at least 1% of the meta device capacity is used.
To use deduplication with encryption, keep in mind that only AES with the CCM mode encryption is compatible with deduplication. For more information, see Managing Encryption Keys.
Data Compression
The data compression property controls whether data is compressed before being written to disk. Shares can optionally compress data before writing to the storage pool. This allows for much greater storage utilization at the expense of increased CPU utilization. By default, no compression is done. If the compression does not yield a minimum space savings, it is not committed to disk to avoid unnecessary decompression when reading back the data. Before choosing a compression algorithm, it is recommended that you perform any necessary performance tests and measure the achieved compression ratio.
| BUI value | CLI value | Description |
|---|---|---|
|
Off |
|
No compression is done. |
|
LZ4 |
|
An algorithm that typically consumes less CPU than GZIP-2, but compresses better than LZJB, depending on the data that is compressed. |
|
LZJB (Fastest) |
|
A simple run-length encoding that only works for sufficiently simple inputs, but does not consume much CPU. |
|
GZIP-2 (Fast) |
|
A lightweight version of the gzip compression algorithm. |
|
GZIP (Default) |
|
The standard gzip compression algorithm. |
|
GZIP-9 (Best Compression) |
|
Highest achievable compression using gzip. This consumes a significant amount of CPU and can often yield only marginal gains. |
Checksum
The checksum property controls the checksum used for data blocks. On the appliance, all data is checksummed on disk, and in such a way to avoid traditional pitfalls (phantom reads and write in particular). This allows the system to detect invalid data returned from the devices. The default checksum (Fletcher4) is sufficient for normal operation, but users can increase the checksum strength at the expense of additional CPU load. Metadata is always checksummed using the same algorithm, so this only affects user data (files or LUN blocks).
| BUI value | CLI value | Description |
|---|---|---|
|
Fletcher 2 (Legacy) |
|
16-bit fletcher checksum |
|
Fletcher 4 (Standard) |
|
32-bit fletcher checksum |
|
SHA-256 (Extra Strong) |
|
SHA-256 checksum |
|
SHA-256-MAC |
|
Cache Device Usage
The cache device usage property controls whether cache devices are used for the share.
By default, all datasets make use of any cache devices on the system. Cache devices are
configured as part of the storage pool and provide an extra layer of caching for faster
tiered access. For more information on cache devices, see Configuring Storage. This property is independent of whether there are any
cache devices currently configured in the storage pool. For example, it is possible to
have this property set to all even if there are no cache devices
present. If any such devices are added in the future, the share will automatically take
advantage of the additional performance. This property does not affect use of the primary
(DRAM) cache.
| BUI Value | CLI Value | Description |
|---|---|---|
|
All data and metadata |
|
All normal file or LUN data is cached, as well as any metadata. |
|
Metadata only |
|
Only metadata is kept on cache devices. This allows for rapid traversal of directory structures, but retrieving file contents may require reading from the data devices. |
|
Do not use cache devices |
|
No data in this share is cached on the cache device. Data is only cached in the primary cache or stored on data devices. |
Synchronous Write Bias
The synchronous write bias property controls the behavior when servicing synchronous writes. By default, the system optimizes synchronous writes for latency, which leverages the log devices to provide fast response times. In a system with multiple disjointed filesystems, this can cause contention on the log devices that can increase latency across all consumers. Even with multiple filesystems requesting synchronous semantics, it may be the case that some filesystems are more latency-sensitive than others.
A common case is a database that has a separate log. The log is extremely latency
sensitive, and while the database itself also requires synchronous semantics, it is
heavier bandwidth and not latency sensitive. In this environment, setting this property to
throughput on the main database while leaving the log filesystem as
latency can result in significant performance improvements. This
setting will change behavior even when no log devices are present, though the effects may
be less dramatic.
The synchronous write bias setting can be bypassed by the Oracle Intelligent Storage Protocol. Instead of using the write bias defined in the file system, Oracle Intelligent Storage Protocol can use the write bias value provided by the Oracle Database NFSv4.0 or NFSv4.1 client. The write bias value sent by the Oracle Database NFSv4.0 or NFSv4.1 client is used only for that write request.
| BUI Value | CLI Value | Description |
|---|---|---|
|
Latency |
|
Synchronous writes are optimized for latency, leveraging the dedicated log device(s), if any. |
|
Throughput |
|
Synchronous writes are optimized for throughput. Data is written to the primary data disks instead of the log device(s), and the writes are performed in a way that optimizes for total bandwidth of the system. Log devices will be used for small amounts of metadata associated with the data writes. |
Database Record Size
The database record size property specifies a suggested block size for files in a filesystem. This property is only valid for filesystems and is designed for use with database workloads that access files in fixed-size records. The system automatically tunes block sizes according to internal algorithms optimized for typical access patterns. For databases that create very large files but access them in small random chunks, these algorithms may be suboptimal. Specifying a record size greater than or equal to the record size of the database can result in significant performance gains. Use of this property for general purpose filesystems is strongly discouraged, and may adversely affect performance.
The default record size is 128 KB. The size specified must be a power of two greater than or equal to 512 and less than or equal to 1 MB. Changing the filesystem's record size affects only files created afterward; existing files and received data are unaffected. If block sizes greater than 128K are used for projects or shares, replication of those projects or shares to systems that do not support large block sizes will fail.
The database record size setting can be bypassed by Oracle Intelligent Storage Protocol. Instead of using the record size defined in the filesystem, Oracle Intelligent Storage Protocol can use the block-size value provided by the Oracle Database NFSv4.0 or NFSv4.1 client. The block size provided by the Oracle Database NFSv4.0 or NFSv4.1 client can only be applied when creating a new database files or table. Block sizes of existing files and tables will not be changed. For more information, see Configuring Oracle ZFS Storage Appliance for Oracle Database Clients.
Additional Replication
The additional replication property controls the number of copies stored of each block, above and beyond any redundancy of the storage pool. Metadata is always stored with multiple copies, but this property allows the same behavior to be applied to data blocks. The storage pool attempts to store these extra blocks on different devices, but it is not guaranteed. In addition, a storage pool cannot be imported if a complete logical device (RAID stripe, mirrored pair, and so on) is lost. This property is not a replacement for proper replication in the storage pool, but can be reassuring for administrators.
Virus Scan
The virus scan property controls whether a filesystem is scanned for viruses. This property is only valid for filesystems. This property setting is independent of the state of the virus scan service. Even if the Virus Scan service is enabled, filesystem scanning must be explicitly enabled using this property. Similarly, virus scanning can be enabled for a particular share even if the service itself is off. For more information about configuration virus scanning, see Virus Scan Configuration.
Prevent Destruction
When set, the share or project cannot be destroyed. This includes destroying a share through dependent clones, destroying a share within a project, or destroying a replication package. However, it does not affect shares destroyed through replication updates. If a share is destroyed on an Oracle ZFS Storage Appliance system that is the source for replication, the corresponding share on the target will be destroyed, even if this property is set. To destroy the share, the property must first be explicitly turned off as a separate step. This property is off by default.
Restrict Ownership Change
By default, ownership of files cannot be changed except by a root user (on a suitable client with a root-enabled export). This property can be turned off on a per-filesystem or per-project basis by turning off this property. When off, file ownership can be changed by the owner of the file or directory, effectively allowing users to "give away" their own files. When ownership is changed, any setuid or setgid bits are stripped, preventing users from escalating privileges through this operation.