Open-E Wiki - User contributions [en]

HTTPS Certificate

2026-02-23T14:48:41Z

Da-F: Created page with "__NOTOC__ The HTTPS Certificate option allows you to configure the SSL/TLS certificate used for secure communication with the system. You can either use the default self-signed certificate delivered with the software or upload your own custom certificate. == Certificate Options == === Self-signed certificate (default) === A self-signed certificate is an identity certificate signed by the same entity whose identity it certifies. This is the default certificate provided..."

__NOTOC__
The HTTPS Certificate option allows you to configure the SSL/TLS certificate used for secure communication with the system. You can either use the default self-signed certificate delivered with the software or upload your own custom certificate.

== Certificate Options ==

=== Self-signed certificate (default) ===

A self-signed certificate is an identity certificate signed by the same entity whose identity it certifies. This is the default certificate provided with the software. The system displays information about the certificate:

*Certificate name
*Certificate Authority
*Expiration date

<br/>'''Note''':

Self-signed certificates are not trusted by browsers by default and may generate security warnings.

=== Custom certificate ===

A custom certificate is signed by a '''Certificate Authority (CA)''' or can be self-generated. Use this option if you want to replace the self-signed certificate with your own trusted certificate. To configure, you must upload both:

*Private key file
*Certificate file

<br/>'''Requirements''': 

• Only private keys encrypted by '''RSA''' or '''ECC (Elliptic Curve Cryptography)''' are supported.
• '''RSA''': Key length must be at least 2048 bits.
• '''ECC''': Supported curves:
• P-256 (secp256r1 or prime256v1)
• P-384 (secp384r1)

After selecting the files, click '''Apply''' to activate the certificate.

=== Applying Changes ===

#Select the certificate type ('''Self-signed or Custom''').
#If '''Custom''', upload the required private key and certificate files.
#Click '''Apply'''.
#The system will immediately apply the new certificate.

== Troubleshooting ==

*'''“Invalid certificate or key” error'''
**Check that the private key and certificate match. Ensure the private key is at least 2048 bits (RSA) or uses a supported ECC curve.
*'''Connection fails after applying a custom certificate'''
**Verify that the uploaded files are not corrupted and the certificate chain is complete (including intermediate certificates if required).
*'''Expired certificate'''
**Replace the certificate with a new one before the expiration date to avoid service interruption.

[[Category:Help topics]]

About

2026-02-19T09:48:38Z

Da-F: Port number required for successful product activation.

This function summarizes all information connected with your license. The detailed information are divided into two panels:

'''ABOUT''' :

*'''Version''' - shows detailed information about the used Release of the JovianDSS

*'''Serial Number ''' - the serial number of your JovianDSS license.

*'''Storage''' - limitation of the usable storage size. There can be a limited size (you will see the maximum value for the storage size) or it can be unlimited.<br/>The '''TRIAL''' license is an Unlimited Storage license. After the '''TRIAL''' period is over, the system's performance will be significantly reduced.

*'''Version status''' - shows the current status of the activation. The status can be either 'Activated' or 'Not Activated'. If the status is 'Not Activated', the button '''ACTIVATE''' will function. In order to activate the product, the system needs an access to the Internet. The communication port needed for the successful activation is 443 (source and destination). In case of any activation errors, please verify your firewall rules.

*'''Expiration date''' : trial license expiration date.

'''LICENSES''' :

License keys should be provided to you from Open-E partner.

'''Product Key '''- Product Key format is XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX'''<br/>Storage Key '''- allows to extend the storage capacity managed by the JovianDSS system.<br/>'''Feature Pack keys''' - adds additional function to the system.

[[Category:Help topics]]

Encryption

2026-02-17T09:15:56Z

Da-F:

__NOTOC__
Encryption protects data stored in datasets and zvols within a ZFS pool (zpool). The encryption feature is available for every zpool, but encrypted resources can be created only after you configure a pool-wide encryption passphrase.

Key characteristics:

*Encryption applies to datasets and zvols; the zpool itself is not encrypted.
*All encrypted resources in one zpool share the same passphrase.
*Datasets and zvols can only be encrypted during their creation.
*You can later change the pool-wide encryption passphrase and the default encryption method.

Use encryption when you need at-rest data protection within a specific zpool.

== Configuring resource encryption ==

#Go to '''Storage'''.
#Select the zpool you want to configure.
#Open the '''Configuration''' tab.
#Expand the '''Resource encryption''' section.

You will see either the initial configuration fields or the current encryption status, depending on whether encryption was already configured or was configured during [[Zpool_wizard|zpool creation]]. When no passphrase is configured for a zpool, the '''Resource encryption''' section shows:

*'''Default encryption method''' – algorithm that is preselected in the drop-down list and used by default for new encrypted datasets and zvols in this zpool, if you do not choose a different method during resource creation.
*'''Encryption passphrase''' – shared passphrase used to unlock all encrypted resources in this zpool.
*'''Confirm passphrase''' – repeat the passphrase for verification.

Enter the passphrase twice, select the default method, and then click '''Save settings'''.

'''Important''': The passphrase cannot be recovered if it is lost. Without the passphrase, encrypted resources in this zpool cannot be accessed.

Once the passphrase is configured, you can start creating encrypted datasets and zvols in this zpool. More details on how to use encryption in resources can be found here:

*Create a new zvol for iSCSI Target
*Create a new zvol for FC Group
*Create a new dataset

'''Notes''':

*Encryption can be enabled only at creation time. Existing datasets and zvols cannot be switched to encrypted mode by editing their properties.
*To protect existing data that is currently unencrypted, you must:
**Create a new encrypted dataset or zvol.
**Copy or replicate data from the old resource to the new encrypted one.
**Remove the unencrypted original if it is no longer needed.

== Managing a zpool with configured resource encryption ==

When a passphrase is already configured, the '''Resource encryption''' section shows:

*'''Passphrase status''' (for example, configured).
*'''Default encryption method'''.
*Buttons:
**Change passphrase
**Change encryption method

=== Changing the encryption passphrase ===

#Click '''Change passphrase'''.
#In the dialog:
##Enter '''New passphrase'''.
##Confirm passphrase.
##Enter the '''Administrator''' password to authorize the change.
#Click '''Change passphrase'''.

After you confirm the change, the new passphrase is propagated to all existing encrypted datasets and zvols in the zpool. This synchronization may take some time, depending on the number of encrypted resources. A notification of the operation's start and completion is recorded in '''Event Viewer'''.

While the synchronization is in progress, the User Interface is locked for changes and cannot be used until the operation finishes.

=== Changing the default encryption method ===

#Click '''Change encryption method'''.
#Select a new '''Default encryption method''' from the drop-down list.
#Click '''Save method'''.

The selected method is displayed as default only for encrypted datasets and zvols created after this change. Existing encrypted resources keep their original encryption method which cannot be changed.

==== Available encryption methods ====

The following methods are available for resource encryption:

'''AES-128-CCM'''

*AES with a 128-bit key in CCM (Counter with CBC-MAC) mode.
*Provides authenticated encryption with moderate CPU usage.
*Suitable when you need a balance between performance and security.

'''AES-192-CCM'''

*AES with a 192-bit key in CCM mode.
*Higher security margin than 128-bit, with slightly higher CPU cost.
*Use when you prefer stronger keys and can accept a small performance impact.

'''AES-256-CCM'''

*AES with a 256-bit key in CCM mode.
*Maximum key length in the CCM group.
*Use when the security margin is more important than performance.

'''AES-128-GCM'''

*AES with a 128-bit key in GCM (Galois/Counter Mode).
*Authenticated encryption optimized for performance on modern CPUs.
*Good choice when you need strong encryption with high throughput.

'''AES-192-GCM'''

*AES with a 192-bit key in GCM mode.
*Increases key size over AES-128-GCM while remaining performant.
*Use when you want a higher security margin but similar behavior to AES-128-GCM.

'''AES-256-GCM'''

*AES with a 256-bit key in GCM mode.
*Provides strong authenticated encryption and is widely used as a best-practice choice.
*Recommended default when your hardware can handle the additional CPU load.

<onlyinclude>
== Handling invalid or missing passphrase ==

If the encryption passphrase is invalid or not configured on the current host, all encrypted datasets and zvols in the affected zpool are locked and cannot be accessed. When a locked zvol is attached to an iSCSI target, FC group, or NVMe-oF subsystem, these objects are effectively blocked as well, and no data can be accessed through them. For an encrypted dataset, all shares configured on it are also blocked.

To restore access, enter the correct passphrase in '''Configuration → Resource encryption''' for the zpool. After a valid passphrase is provided, all locked, encrypted resources are automatically unlocked and become active again, provided that the related targets, groups, subsystems, or datasets were not manually deactivated beforehand.

Such situations may occur, for example, when a zpool is imported on a different host or moved between cluster nodes. In a cluster environment, the passphrase is usually synchronized between nodes, so after a failover, the other node already has the required passphrase. However, if the passphrase change operation was interrupted, some encrypted resources may have been updated to the new passphrase while others still use the old one. On the original host, access may still work, but after exporting the zpool and importing it on another host, some or all encrypted resources can become partially locked. In this case, an event is recorded in the Event Viewer indicating that the passphrase change did not complete successfully.

If this happens, first try to unlock the resources by entering the latest passphrase (the one you intended to change to). If this does not unlock all encrypted resources, enter the previous passphrase (the one used before the change), allow the passphrase change process to complete, and then change the passphrase again to the desired new value. This sequence should unify the passphrase across all encrypted resources in the zpool. Always monitor Event Viewer logs when working with encrypted resources and when changing passphrases.
</onlyinclude>
[[Category:Help topics]]

FC group

2026-02-17T09:11:12Z

Da-F:

__NOTOC__Each pool contains its own configuration for FC. It is assigned to a particular pool and can be used on any machine where a pool is imported. However, FC targets are local to a particular machine and each pool contains mapping of FC targets that has to be used on a particular machine. When the pool is imported on a machine where targets are not assigned to a pool configuration, it is possible to specify them after the pool import.

FC configuration consists of groups that define which volumes are available on given ports to configured initiators. Two type of groups are available: a public group and initiator groups. Public group allows any initiator connected to configured ports to access LUNs assigned to this group. Public group is present on a pool by default and cannot be removed or created. Initially, it didn’t have any volumes or ports assigned, so nothing is available until it is configured manually. Because this group allows to connect any initiator, it is not possible to assign initiators to this group. The second type of FC group is an initiator group. By using this group it is possible to define which initiators can connect to LUNs assigned to a group. Initiator that is not assigned to a FC group won’t be able to connect through ports to LUNs. It is possible to configure many initiator groups to have different access configurations to volumes through FC targets. It is possible to define alias for each initiator group that allows easier identification of the group purpose.

In general, groups gather set of: ports, volumes and initiators. LUNs added to a group define which volumes are available in this group. Ports assigned to a group define on which ports it is possible to connect to LUNs in a particular group. Finally, initiators (in case of an initiator group) define which initiators (ports of remote machines) will be able to connect to LUNs in the group using ports that are assigned to the group. For example, to allow initiators Ini0 and Ini1 access volume Vol-01 through ports P0 and P1 it is required to create an initiator group with assigned ports: P0 and P1, next add volume Vol-01 and initiators Ini0 and Ini1 to this group. It is possible to assign the same volume, initiator or port to more than one group. However, there are some limitations to the configuration that the system won’t allow to be applied:

#The same target cannot be assigned to two groups that share a set of initiators.
#Due to the rule above, the same initiator cannot be assigned to two groups that share a set of ports.
#The target assigned in a public group cannot be used by an initiator group and the other way around, the target assigned to an initiator group cannot be used in public group.
#The target can be assigned to only one pool - the same port cannot be used in two groups that belong to different pools. If the target is used in an active pool and another pool that also uses this target is imported, the group using a conflicting target will be deactivated upon import.

Moreover, a volume used by iSCSI cannot be assigned to any FC group and the other way around.

<br/>A created group can be modified at any point in time. It is possible to assign or remove initiators, ports or volumes. Volumes assigned to groups can be modified, however, it is advised to be careful because in some cases the connected initiator may lose access to the volume during this operation.

It is possible to deactivate any FC group. When a group is inactive, configuration that is represented by that group is not applied to ports thus LUNs are not available to initiators from a given group. A group can be deactivated either manually or by the system in case of configuration conflicts. Configuration conflicts are possible mainly during a foreign pool import. A group is deactivated on the imported pool in case of the following conflicts:

#Target used by the pool is already used by other active pool.
#One of the LUNs uses SCSI ID that is already used by FC or iSCSI LUN on other pool.

A group that was deactivated due to conflict can be activated manually after resolving that conflict by modifying the configuration.

A bit more explanation is required for the SCSI ID uniqueness. This LUN identifier consists of 16 characters, however two SCSI IDs that have the same first 8 characters are considered conflicting. It is due to the way some initiators read those identifiers. Some initiators honor only those first 8 characters of SCSI ID, which could lead to issues if two LUNs would have this part of SCSI ID the same. However, in most cases you don’t have to worry about this setting because the system assigns a unique SCSI ID to the volume based on it’s name and time stamp of creation. When a SCSI ID is not specified, the one assigned to volume is used for a LUN. It is recommended to use a default (generated by system) SCSI ID. To use the default value simply do not specify any SCSI ID during configuration of LUN.

<br/>FC targets assigned to groups require additional configuration to be used in a cluster environment. For detailed description of this configuration please refer to the Edit FC target properties section.

== FC groups and encrypted resources ==
FC Groups can contain a mix of unencrypted and encrypted zvols. However, encryption introduces strict dependency rules that affect the availability of the entire group.

=== Group locking mechanism ===
If any encrypted zvol assigned to an FC Group cannot be accessed due to an encryption issue, the system will:

* Automatically set the FC Group status to '''Locked'''
* Block access to '''all zvols''' in that group, including unencrypted ones
* Prevent initiators from accessing any LUNs assigned to the group

This behavior is intentional and ensures data consistency and security.

In the GUI, encrypted zvols with access issues are marked with an '''error indicator''', and a tooltip may display the cause of the issue (e.g., an incorrect encryption passphrase).

=== Resolving a Locked FC Group ===
If an FC Group is locked:

# Identify encrypted zvols in the group.
# Check their encryption status.
# Unlock the affected zvols by providing the correct encryption passphrase.
# Verify that all encrypted zvols are accessible.

In general, once all encryption issues are resolved, encrypted resources are unlocked automatically and the FC Group returns to '''Active''' status.

In rare cases, automatic activation may fail even though encryption issues have already been resolved. In such situations, deactivating and then reactivating the FC Group can be used to trigger the same validation procedures that are executed after resolving encryption-related errors. If encryption issues are fully resolved, the FC Group and all its resources will activate successfully. If not, the system will prevent activation and display an error.

'''Important:'''
If the FC Group was '''manually deactivated while it was locked''', resolving the encryption issues will still unlock the encrypted resources, but the FC Group will '''remain inactive'''. In this case, the group must be '''manually activated''' to make its resources available to initiators.

=== Detaching blocked zvols as an alternative ===
As an alternative recovery method, a locked FC Group can be restored to an '''Active''' state by '''detaching blocked zvols''' (e.g., encrypted and inaccessible ones) from the FC Group.

Detaching blocked zvols removes them from the group configuration. As a result:

* The FC Group becomes '''Active''' again
* Initiators regain access to the remaining, non-blocked zvols assigned to the group

'''Important Notes'''

After detaching blocked zvols:

* The FC Group operates normally with the remaining zvols.
* Detached zvols remain unavailable until their encryption issues are resolved.

Once detached, encrypted zvols are later unlocked:

* They are '''not automatically reattached or activated.'''
* To make them available again, you must '''manually attach them to the FC Group.'''

This behavior ensures predictable recovery of FC Groups while preventing unintended exposure of storage resources after encryption-related access issues.
{{:Encryption}}

[[Category:Help topics]]

Encryption

2026-02-17T09:10:48Z

Da-F:

Add new zvol

2026-01-15T08:09:27Z

Da-F:

__NOTOC__<onlyinclude>
A zvol is a ZFS block device created inside a ZFS pool (zpool). In this documentation, the term zvol refers to a block-type resource that is typically exported as a LUN to hosts over iSCSI, Fibre Channel, or NVMe-oF. Zvols are usually used to:

* Provide block storage for virtual machines, databases, or other applications that expect a disk device.
* Separate workloads that require different performance or data-protection policies (for example, different compression, block size, or deduplication settings).
* Control how space is consumed by different applications or tenants at the pool level.</onlyinclude>

You first create a zvol, and then (optionally) attach it to a target to make it available to hosts.
<onlyinclude>
== Creating a zvol ==

# Go to the zpool management view in the GUI.
# Select and expand the zpool in which you want to create the zvol.
# Navigate to the iSCSI Targets, FC Targets, or NVMe-oF Targets section.
# Click '''Add zvol''' to open the '''Add new zvol''' dialog.
# Configure '''Encryption settings''' and Zvol properties, and optionally attach to an '''iSCSI''' '''target, NVMe-oF subsystem, or assign to FC groups'''.
# Review the configuration and click '''Add'''. The new zvol appears in the selected zpool.

After creation, you can adjust most properties later; however, encryption and some layout-related parameters (such as volume block size) cannot be changed after data has been written.

=== Encryption settings ===
This section is displayed at the top of the dialog. Encryption can be enabled only during zvol creation and cannot be disabled later for this resource.

==== Encrypt resource ====
Enable this switch to create an encrypted zvol. If the switch remains disabled, the zvol is created unencrypted.

==== Encryption method ====
Defines the encryption algorithm used when the zvol is encrypted.

* By default, the method is inherited from '''Configuration → Resource encryption''' (for example, aes-256-gcm).
* You can select a different supported method for this zvol if required by policy or performance.

For information about keys, unlocking behaviour, and error handling, see the [[Encryption]] article.

=== Zvol properties ===
These fields define the behaviour and performance characteristics of the zvol.

==== Name ====

* The zvol name must be unique within the pool.
* Allowed characters: a–z A–Z 0–9 . _ -

Renaming a zvol that is already exported through a target will change its internal path; any targets using that path must be updated before clients regain access.

==== Size ====

* Defines the logical capacity of the zvol. Enter the value and select the unit (e.g., GiB).
* The dialog shows the currently available physical space in the pool below the field.

Effective space consumption depends on the provisioning mode, compression efficiency, and any additional data copies.

==== Provisioning ====
Controls how space is allocated in the pool.

* '''Thin provisioned (default)''': Physical space is allocated on demand as data is written. This allows you to define logical capacities larger than the pool’s current free space, but you must monitor pool usage to avoid running out of space.
* '''Thick provisioned''': The full size of the zvol is reserved immediately at creation time. This guarantees capacity for the zvol but reduces free space for other resources.

Use thick provisioning only for workloads that require guaranteed capacity and for which overcommitment is unacceptable.

==== Deduplication ====
Enables ZFS block-level deduplication for the zvol. Available options include:

* '''Disabled (default)''' – deduplication is off.
* '''On''' – alias for sha256.
* '''Verify''' – alias for sha256,verify; performs an extra block comparison step.
* '''sha256''' – deduplicates based on SHA-256 checksums; blocks with identical checksums share a single physical copy.
* '''sha256,verify''' – uses SHA-256 and additionally verifies candidate duplicate blocks to reduce the risk of hash collisions. This mode is very resource-intensive.

Use deduplication only when you expect a high ratio of repeated blocks and have sufficient RAM (e.g., many similar VM images). For general-purpose workloads, leaving deduplication disabled is usually recommended.

==== Number of data copies ====
Controls how many ZFS data copies are stored for this zvol, in addition to pool-level redundancy (mirrors, RAIDZ, etc.).

* Allowed values: '''1 (default), 2, 3'''.
* When possible, copies are placed on different physical disks.
* Additional copies increase used space and count against pool capacity.
* Only new writes use the current setting; existing data keeps the number of copies that were in effect when they were written.

Use 2 or 3 copies only for small but critical zvols where additional local redundancy is more important than capacity efficiency.

==== Compression ====
Defines the on-the-fly compression algorithm for zvol data.

* '''lz4 (default)''' – high-performance, general-purpose method that is recommended for most workloads.
* '''None''' – disables compression.
* Additional algorithms in the list:
** gzip-1 … gzip-9 (higher levels compress more but are slower),
** lzjb,
** zle (effective mainly for blocks of zeros).

Keeping lz4 enabled is advisable for most zvols. Disable compression only when the data is already compressed and extremely latency-sensitive.

==== Volume block size ====
Defines the block size used for the zvol. This is similar to choosing a sector size for a virtual disk.

* Values: 4, 8, 16, 32, 64, 128, 256, 512 KiB, and 1 MiB.
* Default value in the dialog: 64 KiB.
* The chosen size cannot be changed once meaningful data has been written.

Guidelines:

* Smaller blocks (e.g., 4-16 KiB) can improve performance for random I/O with small requests, at the cost of more metadata and slightly higher overhead.
* Larger blocks (e.g., 128 KiB or more) are suitable for large sequential workloads, such as backup or media storage.

Choose the block size based on the typical I/O pattern of the applications that will use the zvol.

==== Write cache sync requests ====
Controls how synchronous write operations are handled for this zvol (ZFS sync property).

* '''Always (default)''': All writes are treated as synchronous. Each transaction is committed and flushed to stable storage before the operation returns to the initiator. This provides the highest level of data safety and is recommended especially when no reliable UPS is available.
* '''Standard''': Equivalent to sync=standard. Only writes that are explicitly requested as synchronous are forced to stable storage; other writes can stay cached for up to about one second before being committed. This improves performance, but the most recent (up to 1 second) cached data can be lost in case of a power outage. Use this option only in environments protected by a reliable UPS.
* '''Disabled''': Equivalent to sync=disabled. Even explicitly synchronous writes are treated as asynchronous and may remain in cache for up to about one second. This provides the highest performance, but the most recent cached data may be lost during a power outage, and applications may observe inconsistent data. Use this option only for non-critical workloads and only in environments equipped with a reliable UPS.

==== Write cache sync request handling (logbias) ====
Provides a hint about how synchronous writes should use log devices (if present in the pool).

* '''Write log device (Latency)''': If dedicated log vdevs exist, they are used to minimize latency for synchronous writes. This is the recommended default for latency-sensitive workloads.
* '''In pool (Throughput)''': Log vdevs are bypassed, and writes are optimized for aggregate throughput and efficient pool usage. This can be beneficial for streaming workloads where latency is less critical.

This setting does not override pool layout; it only influences where synchronous data is staged before being committed to main storage.

==== Read cache (primary, ARC) scope ====
Specifies what is cached in the primary memory cache (ARC) for this zvol.

* '''All (default)''' – cache both data and metadata.
* '''Metadata''' – cache only metadata; user data is read directly from disk.
* '''None''' – do not cache anything for this zvol in ARC.

For large, sequential, or low-priority workloads you can reduce ARC pressure by switching to '''Metadata''' or '''None'''.

==== Read cache (secondary, L2ARC) scope ====
Controls use of secondary cache devices (L2ARC), typically SSDs.

* '''All (default)''' – cache both metadata and user data on L2ARC.
* '''Metadata''' – cache only metadata on L2ARC.
* '''None''' – exclude this zvol from L2ARC caching.

Use '''Metadata''' or '''None''' for zvols that would otherwise fill L2ARC with data that has low reuse value, thereby preserving cache space for more critical workloads.</onlyinclude>

=== Attach to target ===
The '''Attach to target''' section at the bottom of the dialog allows you to export the newly created zvol as a LUN immediately. This section is optional; you can also attach the zvol later from the target configuration views.

==== General behaviour ====

* When the Attach to target checkbox is disabled, the zvol is created but not attached to any target.
* Enabling the checkbox expands the configuration panel and allows you to select or configure how the zvol will be presented to initiators.

==== Fields ====
'''Target name''': Select an existing target from the drop-down list. The zvol will be attached as a new LUN under this target.

==== SCSI ID ====

* '''Automatic''' – uses an automatically generated SCSI identifier.
* '''Generate''' – creates a new random identifier if you need to control or refresh the ID.

In most cases, leaving the default automatic value is sufficient.

==== LUN ====

* '''automatic''' – assigns the next available LUN number on the selected target.
* '''manual entry''' – specify a particular LUN number if your environment uses a specific numbering scheme; the number must not already be in use on that target.

==== Write cache settings ====
Defines how write caching is presented to the initiator for this LUN.

* '''Write-through --- Block I/O (default)''': All writes are committed directly to stable storage before completion is reported to the initiator. This mode prioritizes data integrity and is recommended for most environments.
* '''Read only --- Block I/O''': Exposes the LUN as read-only on the Block I/O path. Any write attempts from the initiator are rejected. Use this option for volumes that must not be modified.
* '''Write-through --- File I/O''': Similar to Write-through --- Block I/O, but handled through the File I/O path. Writes are acknowledged only after they are safely stored on disk.
* '''Write-back --- File I/O''': Enables write-back caching on the File I/O path. Write requests are acknowledged after being stored in cache rather than on disk, which provides the highest write performance. However, cached data may be lost in case of a power failure or node crash (this risk exists even in HA cluster configurations), and resource failover can take noticeably longer. Use this option only when the environment can tolerate potential data loss and when additional protection (e.g., a battery-backed cache and a reliable UPS) is in place.
* '''Read only --- File I/O''': Exposes the LUN as read-only on the File I/O path. Use when the initiator must have read access only, for example, for archival or reference datasets.

==== TRIM support ====

* When enabled, it allows the zvol to honor TRIM / UNMAP requests from the initiator so that released blocks can be returned to the pool.
* Use this option only when the operating system and initiator software fully support TRIM for the relevant protocol.

TRIM can improve space efficiency for thin-provisioned zvols, but misconfigured initiators or unsupported combinations may cause unexpected behaviour.

After you confirm the configuration and click Add, the zvol is created with the specified properties. If attachment is enabled, the zvol is also exposed as a LUN on the selected target and becomes available to connected initiators after they rescan their devices.
[[Category:Help topics]]

Add FC volume

2026-01-15T08:07:28Z

Da-F:

__NOTOC__{{:Add new zvol}}
=== Attach to Fibre Channel groups ===
This section allows you to assign the new zvol to one or more Fibre Channel (FC) groups and control how it will be presented to FC initiators.

==== FC membership properties ====

===== SCSI ID =====
A unique identifier of a device.

* '''Automatic''' – a SCSI identifier is generated automatically.
* '''Generate''' – creates a new random SCSI identifier.

In most cases, leaving the value set to '''automatic''' is sufficient.

===== Write cache settings =====
Defines how write caching is exposed for this FC LUN:

* '''Write-through --- Block I/O (default)''' – write requests are completed only after data is safely stored on disk. Recommended for most environments.
* '''Write-through --- File I/O''' – write-through behaviour using the File I/O path.
* '''Write-back --- File I/O''' – enables write-back caching on the File I/O path. This provides the highest write performance, but cached data can be lost in case of a power outage or node failure (even in HA cluster mode). Use only when the environment can tolerate potential data loss and when appropriate protection such as UPS and battery-backed cache is in place.
* '''Read only --- File I/O''' – exposes the LUN as read-only over File I/O.
* '''Read only --- Block I/O''' – exposes the LUN as read-only over Block I/O.

===== TRIM support =====
When enabled, allows the FC LUN to accept TRIM/UNMAP commands, returning freed blocks to the pool. Use this option only when the initiator and operating system fully support TRIM over Fibre Channel.

===== FC groups =====
The '''FC groups''' table lists all configured Fibre Channel groups.

* '''Alias''' – name of the FC group. Select the check box to assign the zvol to that group.
* '''LUN''' – LUN number under which the zvol will be exposed in the selected group.
** Auto-assigns the next available LUN number.
** If manual entry is allowed, you can type a specific LUN number that is free within that group.

If no FC group is selected, the zvol will not be available over Fibre Channel and can be assigned later from the FC configuration view.
[[Category:Help topics]]

Add new zvol

2026-01-15T08:02:53Z

Da-F:

__NOTOC__<onlyinclude>A zvol is a ZFS block device created inside a ZFS pool (zpool). In this documentation, the term zvol refers to a block-type resource that is typically exported as a LUN to hosts over iSCSI, Fibre Channel, or NVMe-oF. Zvols are usually used to:

* Provide block storage for virtual machines, databases, or other applications that expect a disk device.
* Separate workloads that require different performance or data-protection policies (for example, different compression, block size, or deduplication settings).
* Control how space is consumed by different applications or tenants at the pool level.</onlyinclude>

You first create a zvol, and then (optionally) attach it to a target to make it available to hosts.

<onlyinclude>== Creating a zvol ==

# Go to the zpool management view in the GUI.
# Select and expand the zpool in which you want to create the zvol.
# Navigate to the iSCSI Targets, FC Targets, or NVMe-oF Targets section.
# Click '''Add zvol''' to open the '''Add new zvol''' dialog.
# Configure '''Encryption settings''' and Zvol properties, and optionally attach to an '''iSCSI''' '''target, NVMe-oF subsystem, or assign to FC groups'''.
# Review the configuration and click '''Add'''. The new zvol appears in the selected zpool.

After creation, you can adjust most properties later; however, encryption and some layout-related parameters (such as volume block size) cannot be changed after data has been written.

=== Encryption settings ===
This section is displayed at the top of the dialog. Encryption can be enabled only during zvol creation and cannot be disabled later for this resource.

==== Encrypt resource ====
Enable this switch to create an encrypted zvol. If the switch remains disabled, the zvol is created unencrypted.

==== Encryption method ====
Defines the encryption algorithm used when the zvol is encrypted.

* By default, the method is inherited from '''Configuration → Resource encryption''' (for example, aes-256-gcm).
* You can select a different supported method for this zvol if required by policy or performance.

For information about keys, unlocking behaviour, and error handling, see the [[Encryption]] article.

=== Zvol properties ===
These fields define the behaviour and performance characteristics of the zvol.

==== Name ====

* The zvol name must be unique within the pool.
* Allowed characters: a–z A–Z 0–9 . _ -

Renaming a zvol that is already exported through a target will change its internal path; any targets using that path must be updated before clients regain access.

==== Size ====

* Defines the logical capacity of the zvol. Enter the value and select the unit (e.g., GiB).
* The dialog shows the currently available physical space in the pool below the field.

Effective space consumption depends on the provisioning mode, compression efficiency, and any additional data copies.

==== Provisioning ====
Controls how space is allocated in the pool.

* '''Thin provisioned (default)''': Physical space is allocated on demand as data is written. This allows you to define logical capacities larger than the pool’s current free space, but you must monitor pool usage to avoid running out of space.
* '''Thick provisioned''': The full size of the zvol is reserved immediately at creation time. This guarantees capacity for the zvol but reduces free space for other resources.

Use thick provisioning only for workloads that require guaranteed capacity and for which overcommitment is unacceptable.

==== Deduplication ====
Enables ZFS block-level deduplication for the zvol. Available options include:

* '''Disabled (default)''' – deduplication is off.
* '''On''' – alias for sha256.
* '''Verify''' – alias for sha256,verify; performs an extra block comparison step.
* '''sha256''' – deduplicates based on SHA-256 checksums; blocks with identical checksums share a single physical copy.
* '''sha256,verify''' – uses SHA-256 and additionally verifies candidate duplicate blocks to reduce the risk of hash collisions. This mode is very resource-intensive.

Use deduplication only when you expect a high ratio of repeated blocks and have sufficient RAM (e.g., many similar VM images). For general-purpose workloads, leaving deduplication disabled is usually recommended.

==== Number of data copies ====
Controls how many ZFS data copies are stored for this zvol, in addition to pool-level redundancy (mirrors, RAIDZ, etc.).

* Allowed values: '''1 (default), 2, 3'''.
* When possible, copies are placed on different physical disks.
* Additional copies increase used space and count against pool capacity.
* Only new writes use the current setting; existing data keeps the number of copies that were in effect when they were written.

Use 2 or 3 copies only for small but critical zvols where additional local redundancy is more important than capacity efficiency.

==== Compression ====
Defines the on-the-fly compression algorithm for zvol data.

* '''lz4 (default)''' – high-performance, general-purpose method that is recommended for most workloads.
* '''None''' – disables compression.
* Additional algorithms in the list:
** gzip-1 … gzip-9 (higher levels compress more but are slower),
** lzjb,
** zle (effective mainly for blocks of zeros).

Keeping lz4 enabled is advisable for most zvols. Disable compression only when the data is already compressed and extremely latency-sensitive.

==== Volume block size ====
Defines the block size used for the zvol. This is similar to choosing a sector size for a virtual disk.

* Values: 4, 8, 16, 32, 64, 128, 256, 512 KiB, and 1 MiB.
* Default value in the dialog: 64 KiB.
* The chosen size cannot be changed once meaningful data has been written.

Guidelines:

* Smaller blocks (e.g., 4-16 KiB) can improve performance for random I/O with small requests, at the cost of more metadata and slightly higher overhead.
* Larger blocks (e.g., 128 KiB or more) are suitable for large sequential workloads, such as backup or media storage.

Choose the block size based on the typical I/O pattern of the applications that will use the zvol.

==== Write cache sync requests ====
Controls how synchronous write operations are handled for this zvol (ZFS sync property).

* '''Always (default)''': All writes are treated as synchronous. Each transaction is committed and flushed to stable storage before the operation returns to the initiator. This provides the highest level of data safety and is recommended especially when no reliable UPS is available.
* '''Standard''': Equivalent to sync=standard. Only writes that are explicitly requested as synchronous are forced to stable storage; other writes can stay cached for up to about one second before being committed. This improves performance, but the most recent (up to 1 second) cached data can be lost in case of a power outage. Use this option only in environments protected by a reliable UPS.
* '''Disabled''': Equivalent to sync=disabled. Even explicitly synchronous writes are treated as asynchronous and may remain in cache for up to about one second. This provides the highest performance, but the most recent cached data may be lost during a power outage, and applications may observe inconsistent data. Use this option only for non-critical workloads and only in environments equipped with a reliable UPS.

==== Write cache sync request handling (logbias) ====
Provides a hint about how synchronous writes should use log devices (if present in the pool).

* '''Write log device (Latency)''': If dedicated log vdevs exist, they are used to minimize latency for synchronous writes. This is the recommended default for latency-sensitive workloads.
* '''In pool (Throughput)''': Log vdevs are bypassed, and writes are optimized for aggregate throughput and efficient pool usage. This can be beneficial for streaming workloads where latency is less critical.

This setting does not override pool layout; it only influences where synchronous data is staged before being committed to main storage.

==== Read cache (primary, ARC) scope ====
Specifies what is cached in the primary memory cache (ARC) for this zvol.

* '''All (default)''' – cache both data and metadata.
* '''Metadata''' – cache only metadata; user data is read directly from disk.
* '''None''' – do not cache anything for this zvol in ARC.

For large, sequential, or low-priority workloads you can reduce ARC pressure by switching to '''Metadata''' or '''None'''.

==== Read cache (secondary, L2ARC) scope ====
Controls use of secondary cache devices (L2ARC), typically SSDs.

* '''All (default)''' – cache both metadata and user data on L2ARC.
* '''Metadata''' – cache only metadata on L2ARC.
* '''None''' – exclude this zvol from L2ARC caching.

Use '''Metadata''' or '''None''' for zvols that would otherwise fill L2ARC with data that has low reuse value, thereby preserving cache space for more critical workloads.</onlyinclude>

=== Attach to target ===
The '''Attach to target''' section at the bottom of the dialog allows you to export the newly created zvol as a LUN immediately. This section is optional; you can also attach the zvol later from the target configuration views.

==== General behaviour ====

* When the Attach to target checkbox is disabled, the zvol is created but not attached to any target.
* Enabling the checkbox expands the configuration panel and allows you to select or configure how the zvol will be presented to initiators.

==== Fields ====
'''Target name''': Select an existing target from the drop-down list. The zvol will be attached as a new LUN under this target.

==== SCSI ID ====

* '''Automatic''' – uses an automatically generated SCSI identifier.
* '''Generate''' – creates a new random identifier if you need to control or refresh the ID.

In most cases, leaving the default automatic value is sufficient.

==== LUN ====

* '''automatic''' – assigns the next available LUN number on the selected target.
* '''manual entry''' – specify a particular LUN number if your environment uses a specific numbering scheme; the number must not already be in use on that target.

==== Write cache settings ====
Defines how write caching is presented to the initiator for this LUN.

* '''Write-through --- Block I/O (default)''': All writes are committed directly to stable storage before completion is reported to the initiator. This mode prioritizes data integrity and is recommended for most environments.
* '''Read only --- Block I/O''': Exposes the LUN as read-only on the Block I/O path. Any write attempts from the initiator are rejected. Use this option for volumes that must not be modified.
* '''Write-through --- File I/O''': Similar to Write-through --- Block I/O, but handled through the File I/O path. Writes are acknowledged only after they are safely stored on disk.
* '''Write-back --- File I/O''': Enables write-back caching on the File I/O path. Write requests are acknowledged after being stored in cache rather than on disk, which provides the highest write performance. However, cached data may be lost in case of a power failure or node crash (this risk exists even in HA cluster configurations), and resource failover can take noticeably longer. Use this option only when the environment can tolerate potential data loss and when additional protection (e.g., a battery-backed cache and a reliable UPS) is in place.
* '''Read only --- File I/O''': Exposes the LUN as read-only on the File I/O path. Use when the initiator must have read access only, for example, for archival or reference datasets.

==== TRIM support ====

* When enabled, it allows the zvol to honor TRIM / UNMAP requests from the initiator so that released blocks can be returned to the pool.
* Use this option only when the operating system and initiator software fully support TRIM for the relevant protocol.

TRIM can improve space efficiency for thin-provisioned zvols, but misconfigured initiators or unsupported combinations may cause unexpected behaviour.

After you confirm the configuration and click Add, the zvol is created with the specified properties. If attachment is enabled, the zvol is also exposed as a LUN on the selected target and becomes available to connected initiators after they rescan their devices.
[[Category:Help topics]]

Add new zvol

2026-01-15T07:58:32Z

Da-F:

__NOTOC__A zvol is a ZFS block device created inside a ZFS pool (zpool). In this documentation, the term zvol refers to a block-type resource that is typically exported as a LUN to hosts over iSCSI, Fibre Channel, or NVMe-oF. Zvols are usually used to:

* Provide block storage for virtual machines, databases, or other applications that expect a disk device.
* Separate workloads that require different performance or data-protection policies (for example, different compression, block size, or deduplication settings).
* Control how space is consumed by different applications or tenants at the pool level.

You first create a zvol, and then (optionally) attach it to a target to make it available to hosts.

== Creating a zvol ==

# Go to the zpool management view in the GUI.
# Select and expand the zpool in which you want to create the zvol.
# Navigate to the iSCSI Targets, FC Targets, or NVMe-oF Targets section.
# Click '''Add zvol''' to open the '''Add new zvol''' dialog.
# Configure '''Encryption settings''' and Zvol properties, and optionally attach to an '''iSCSI''' '''target, NVMe-oF subsystem, or assign to FC groups'''.
# Review the configuration and click '''Add'''. The new zvol appears in the selected zpool.

After creation, you can adjust most properties later; however, encryption and some layout-related parameters (such as volume block size) cannot be changed after data has been written.

=== Encryption settings ===
This section is displayed at the top of the dialog. Encryption can be enabled only during zvol creation and cannot be disabled later for this resource.

==== Encrypt resource ====
Enable this switch to create an encrypted zvol. If the switch remains disabled, the zvol is created unencrypted.

==== Encryption method ====
Defines the encryption algorithm used when the zvol is encrypted.

* By default, the method is inherited from '''Configuration → Resource encryption''' (for example, aes-256-gcm).
* You can select a different supported method for this zvol if required by policy or performance.

For information about keys, unlocking behaviour, and error handling, see the [[Encryption]] article.

=== Zvol properties ===
These fields define the behaviour and performance characteristics of the zvol.

==== Name ====

* The zvol name must be unique within the pool.
* Allowed characters: a–z A–Z 0–9 . _ -

Renaming a zvol that is already exported through a target will change its internal path; any targets using that path must be updated before clients regain access.

==== Size ====

* Defines the logical capacity of the zvol. Enter the value and select the unit (e.g., GiB).
* The dialog shows the currently available physical space in the pool below the field.

Effective space consumption depends on the provisioning mode, compression efficiency, and any additional data copies.

==== Provisioning ====
Controls how space is allocated in the pool.

* '''Thin provisioned (default)''': Physical space is allocated on demand as data is written. This allows you to define logical capacities larger than the pool’s current free space, but you must monitor pool usage to avoid running out of space.
* '''Thick provisioned''': The full size of the zvol is reserved immediately at creation time. This guarantees capacity for the zvol but reduces free space for other resources.

Use thick provisioning only for workloads that require guaranteed capacity and for which overcommitment is unacceptable.

==== Deduplication ====
Enables ZFS block-level deduplication for the zvol. Available options include:

* '''Disabled (default)''' – deduplication is off.
* '''On''' – alias for sha256.
* '''Verify''' – alias for sha256,verify; performs an extra block comparison step.
* '''sha256''' – deduplicates based on SHA-256 checksums; blocks with identical checksums share a single physical copy.
* '''sha256,verify''' – uses SHA-256 and additionally verifies candidate duplicate blocks to reduce the risk of hash collisions. This mode is very resource-intensive.

Use deduplication only when you expect a high ratio of repeated blocks and have sufficient RAM (e.g., many similar VM images). For general-purpose workloads, leaving deduplication disabled is usually recommended.

==== Number of data copies ====
Controls how many ZFS data copies are stored for this zvol, in addition to pool-level redundancy (mirrors, RAIDZ, etc.).

* Allowed values: '''1 (default), 2, 3'''.
* When possible, copies are placed on different physical disks.
* Additional copies increase used space and count against pool capacity.
* Only new writes use the current setting; existing data keeps the number of copies that were in effect when they were written.

Use 2 or 3 copies only for small but critical zvols where additional local redundancy is more important than capacity efficiency.

==== Compression ====
Defines the on-the-fly compression algorithm for zvol data.

* '''lz4 (default)''' – high-performance, general-purpose method that is recommended for most workloads.
* '''None''' – disables compression.
* Additional algorithms in the list:
** gzip-1 … gzip-9 (higher levels compress more but are slower),
** lzjb,
** zle (effective mainly for blocks of zeros).

Keeping lz4 enabled is advisable for most zvols. Disable compression only when the data is already compressed and extremely latency-sensitive.

==== Volume block size ====
Defines the block size used for the zvol. This is similar to choosing a sector size for a virtual disk.

* Values: 4, 8, 16, 32, 64, 128, 256, 512 KiB, and 1 MiB.
* Default value in the dialog: 64 KiB.
* The chosen size cannot be changed once meaningful data has been written.

Guidelines:

* Smaller blocks (e.g., 4-16 KiB) can improve performance for random I/O with small requests, at the cost of more metadata and slightly higher overhead.
* Larger blocks (e.g., 128 KiB or more) are suitable for large sequential workloads, such as backup or media storage.

Choose the block size based on the typical I/O pattern of the applications that will use the zvol.

==== Write cache sync requests ====
Controls how synchronous write operations are handled for this zvol (ZFS sync property).

* '''Always (default)''': All writes are treated as synchronous. Each transaction is committed and flushed to stable storage before the operation returns to the initiator. This provides the highest level of data safety and is recommended especially when no reliable UPS is available.
* '''Standard''': Equivalent to sync=standard. Only writes that are explicitly requested as synchronous are forced to stable storage; other writes can stay cached for up to about one second before being committed. This improves performance, but the most recent (up to 1 second) cached data can be lost in case of a power outage. Use this option only in environments protected by a reliable UPS.
* '''Disabled''': Equivalent to sync=disabled. Even explicitly synchronous writes are treated as asynchronous and may remain in cache for up to about one second. This provides the highest performance, but the most recent cached data may be lost during a power outage, and applications may observe inconsistent data. Use this option only for non-critical workloads and only in environments equipped with a reliable UPS.

==== Write cache sync request handling (logbias) ====
Provides a hint about how synchronous writes should use log devices (if present in the pool).

* '''Write log device (Latency)''': If dedicated log vdevs exist, they are used to minimize latency for synchronous writes. This is the recommended default for latency-sensitive workloads.
* '''In pool (Throughput)''': Log vdevs are bypassed, and writes are optimized for aggregate throughput and efficient pool usage. This can be beneficial for streaming workloads where latency is less critical.

This setting does not override pool layout; it only influences where synchronous data is staged before being committed to main storage.

==== Read cache (primary, ARC) scope ====
Specifies what is cached in the primary memory cache (ARC) for this zvol.

* '''All (default)''' – cache both data and metadata.
* '''Metadata''' – cache only metadata; user data is read directly from disk.
* '''None''' – do not cache anything for this zvol in ARC.

For large, sequential, or low-priority workloads you can reduce ARC pressure by switching to '''Metadata''' or '''None'''.

==== Read cache (secondary, L2ARC) scope ====
Controls use of secondary cache devices (L2ARC), typically SSDs.

* '''All (default)''' – cache both metadata and user data on L2ARC.
* '''Metadata''' – cache only metadata on L2ARC.
* '''None''' – exclude this zvol from L2ARC caching.

Use '''Metadata''' or '''None''' for zvols that would otherwise fill L2ARC with data that has low reuse value, thereby preserving cache space for more critical workloads.

=== Attach to target ===
The '''Attach to target''' section at the bottom of the dialog allows you to export the newly created zvol as a LUN immediately. This section is optional; you can also attach the zvol later from the target configuration views.

==== General behaviour ====

* When the Attach to target checkbox is disabled, the zvol is created but not attached to any target.
* Enabling the checkbox expands the configuration panel and allows you to select or configure how the zvol will be presented to initiators.

==== Fields ====
'''Target name''': Select an existing target from the drop-down list. The zvol will be attached as a new LUN under this target.

==== SCSI ID ====

* '''Automatic''' – uses an automatically generated SCSI identifier.
* '''Generate''' – creates a new random identifier if you need to control or refresh the ID.

In most cases, leaving the default automatic value is sufficient.

==== LUN ====

* '''automatic''' – assigns the next available LUN number on the selected target.
* '''manual entry''' – specify a particular LUN number if your environment uses a specific numbering scheme; the number must not already be in use on that target.

==== Write cache settings ====
Defines how write caching is presented to the initiator for this LUN.

* '''Write-through --- Block I/O (default)''': All writes are committed directly to stable storage before completion is reported to the initiator. This mode prioritizes data integrity and is recommended for most environments.
* '''Read only --- Block I/O''': Exposes the LUN as read-only on the Block I/O path. Any write attempts from the initiator are rejected. Use this option for volumes that must not be modified.
* '''Write-through --- File I/O''': Similar to Write-through --- Block I/O, but handled through the File I/O path. Writes are acknowledged only after they are safely stored on disk.
* '''Write-back --- File I/O''': Enables write-back caching on the File I/O path. Write requests are acknowledged after being stored in cache rather than on disk, which provides the highest write performance. However, cached data may be lost in case of a power failure or node crash (this risk exists even in HA cluster configurations), and resource failover can take noticeably longer. Use this option only when the environment can tolerate potential data loss and when additional protection (e.g., a battery-backed cache and a reliable UPS) is in place.
* '''Read only --- File I/O''': Exposes the LUN as read-only on the File I/O path. Use when the initiator must have read access only, for example, for archival or reference datasets.

==== TRIM support ====

* When enabled, it allows the zvol to honor TRIM / UNMAP requests from the initiator so that released blocks can be returned to the pool.
* Use this option only when the operating system and initiator software fully support TRIM for the relevant protocol.

TRIM can improve space efficiency for thin-provisioned zvols, but misconfigured initiators or unsupported combinations may cause unexpected behaviour.

After you confirm the configuration and click Add, the zvol is created with the specified properties. If attachment is enabled, the zvol is also exposed as a LUN on the selected target and becomes available to connected initiators after they rescan their devices.
[[Category:Help topics]]

Dataset

2026-01-15T07:52:58Z

Da-F:

__NOTOC__A '''dataset''' is a ZFS file system created inside a ZFS pool (zpool). In this documentation, dataset always refers to a file-system resource, typically used as NAS storage for SMB / NFS shares.

Datasets are typically used to:

* Provide NAS volumes for SMB and NFS shares.
* Separate data sets with different performance or data-protection policies (for example, different compression, recordsize, or deduplication settings).
* Apply independent quota and reservation limits for different workloads or tenants.

You create a dataset first, then create shares (SMB / NFS, etc.) that point to it.

== Creating a dataset ==

# Go to the pool management view in the GUI.
# Select and expand the zpool where you want to create the dataset.
# Navigate to the '''Shares''' section for the selected zpool.
# Click '''Add dataset''' to open the dataset creation dialog.
# Configure the parameters.
# Review and confirm creation. The new dataset appears in the dataset list for the selected zpool.

After creation, you can:

* Assign SMB or NFS shares to the dataset in the appropriate shares configuration pages.
* Adjust most dataset properties later; however, '''encryption settings''' and some layout-related properties cannot be changed after creation.

Below is a description of all dataset properties.

=== Encryption settings ===
This section is displayed at the top of the dialog. '''Encryption is available only during creation and cannot be disabled later'''. Once the dataset is created, you cannot turn encryption off for it.

==== Encrypt resource ====
Enable this switch to create an encrypted dataset. When disabled, the dataset is created unencrypted.

==== Encryption method ====
Shows the algorithm used when the dataset is encrypted.

* By default, it inherits the value from the Configuration -> Resource encryption setting (for example, aes-256-gcm).
* You can select a different supported method for this dataset.

For details about keys, unlocking, and error handling, see [[Encryption]].

=== Dataset properties ===
These fields define the behaviour of the dataset itself.

==== Name ====

* The dataset name must be unique within the pool.
* Allowed characters: a–z A–Z 0–9 . _ -

Changing the name of an existing dataset breaks paths used by its shares; clients will lose access until the share definitions are adjusted.

==== Deduplication ====
Enables ZFS block-level deduplication for this dataset. Options:

* Disabled (default) – deduplication is turned off.
* On – alias for “sha256”.
* Verify – alias for "sha256, Verify"; additionally compares blocks to reduce the risk of false matches.
* sha256 - uses the SHA-256 checksum for deduplication. When two blocks have the same checksum, they are treated as identical and only a single copy is stored.
* sha256, Verify – uses SHA-256 for deduplication and additionally verifies candidate duplicate blocks to detect possible hash collisions. This mode is very resource-intensive and is not recommended for general use.

Use deduplication only for workloads with a high ratio of identical blocks and sufficient RAM (e.g., many similar VM images). For general data, it is usually better to keep it disabled.

==== Number of data copies ====
Controls the number of ZFS data copies stored for this dataset, in addition to pool redundancy (mirror, RAIDZ, and so on).

* Possible values: '''1 (default)''', '''2''', '''3'''.
* Copies are stored on different disks when possible.
* Extra copies increase used space and are counted towards quota and reservation.
* Only new writes use the current setting.

Use higher values only for small but critical datasets where local redundancy is more important than capacity.

==== Compression ====
The compression algorithm used for this dataset.

* Default: '''lz4 (default)''' – fast, generally recommended.
* '''None''' – disables compression.
* Other algorithms that can appear in the list:
** gzip levels 1–9 (1 = fastest, lowest compression; 9 = slowest, highest compression),
** lzjb,
** zle.

Keep lz4 for most datasets. Disable compression only when data is already compressed and very latency-sensitive.

==== Record size ====
Suggested block size for files stored in this dataset.

* Designed primarily for database-type workloads that access large files in fixed-size records.
* For such workloads, setting the “record size” to at least match the database record size can significantly improve performance.
* For general-purpose datasets, changing the default is not recommended and may reduce performance.
* Values: 4, 8, 16, 32, 64, 128, 256, 512 KiB and 1 MiB; newer software versions allow values up to 16 MiB.
* Default: '''128 KiB (default)'''.

The new record size applies only to data written after the change; existing files keep their original block size.

==== Write cache sync requests ====
Controls the ZFS '''sync''' property – how synchronous write operations are handled.

Options in the drop-down:

* '''Always''': All file-system transactions are committed and flushed to stable storage before returning to the application. Best data safety; lower performance.
* '''Standard (default)''': Synchronous operations are logged and flushed; however, to improve performance, the most recent cached data (approximately one second) may be lost if a sudden power failure occurs. Recommended only when the environment is protected by a reliable UPS, as indicated by the warning in the dialog.
* '''Disabled''': Synchronous requests are treated as asynchronous; data is committed only when the next transaction group is written. This provides maximum performance but the highest risk of data loss and inconsistency. Use only for non-critical workloads where this risk is acceptable.

==== Write cache sync request handling (logbias) ====
Gives a hint how synchronous writes for this dataset should use log devices.

* '''Write log device (Latency)''' – if the pool has separate log devices, they are used to minimize latency of synchronous writes. Recommended default.
* '''In pool (Throughput)''' – log devices are not used; the software optimizes for overall pool throughput and efficient use of resources.

==== Read cache (primary, ARC) scope ====
Controls what is cached in main memory (ARC) for this dataset.

* '''All (default)''' – cache data and metadata.
* '''Metadata''' – cache only metadata.
* '''None''' – do not cache anything from this dataset in ARC.

You can reduce ARC pressure for large streaming or low-priority datasets by switching to “Metadata” or “None”.

==== Read cache (secondary, L2ARC) scope ====
Controls what is cached on L2ARC devices (if present).

* '''All (default)''' – cache data and metadata.
* '''Metadata''' – cache only metadata.
* '''None''' – do not cache this dataset in L2ARC.

Use “Metadata” or “None” for datasets that would otherwise fill L2ARC with low-value data.

==== Access time ====
Controls whether file access time (atime) is updated on reads.

* '''Disabled (default)''' – access time is not updated, which avoids extra writes and can significantly improve performance.
* '''Enabled''' – access time is updated on each read; required by some legacy applications (for example, certain mailers).

=== Small data blocks policy ===
This section controls how '''small data blocks''' of this dataset are placed when the pool has a '''special devices group''' configured.

* If no special devices group exists in the pool, the section is disabled, and an information banner appears: “Available only when a special devices group exists.” In this case, all data blocks are stored on regular data vdevs.
* When a special devices group exists and is healthy, the '''Small data block size''' list becomes active.

==== Small data block size ====
Defines the maximum size of blocks that will be stored on special devices instead of regular data vdevs (this corresponds to the ZFS special_small_blocks property for the dataset). More info available in the “[[Small blocks policy settings]]” article.

Available options in the drop-down:

* '''Disable for the dataset''': The small data blocks policy is disabled for this dataset, regardless of the pool settings. All data blocks (including small ones) are stored on regular data vdevs.
* '''4 KiB, 8 KiB, 16 KiB, 32 KiB, 64 KiB, 128 KiB, 256 KiB, 512 KiB, 1 MiB, 2 MiB, 4 MiB, 8 MiB, 16 MiB''': Any data block with a logical size less than or equal to the selected value is stored on special devices. Larger blocks are stored on regular data vdevs.
* '''Inherit from the pool settings (default) [X KiB]''': The dataset inherits the pool-level small blocks setting. The value in brackets ([X KiB]) shows the current pool threshold; e.g.:
** [0 KiB] – small data blocks policy is effectively disabled on the pool.
** [128 KiB] – blocks up to 128 KiB are redirected to special devices according to pool settings.

Notes and recommendations

* A '''higher threshold''' moves more data to special devices, which can improve performance for small, random I/O, but also increases capacity usage on the special devices group.
* A '''very small value''' (e.g., 4 KiB or 8 KiB) typically limits the placement mostly to metadata and very small files.
* If special or dedup devices are not supported by the pool layout (e.g., the pool contains RAIDZ data groups instead of mirror-based data vdevs), the small data blocks policy cannot be effectively used. Plan the pool layout accordingly.
* If the special devices group becomes degraded or unavailable, the performance and behaviour of datasets using the small data blocks policy can be affected; always monitor pool health.

=== Space management – quota and reservation ===
The bottom part of the dialog controls space limits for the dataset.

==== Enable quota ====
When this switch is enabled:

* '''Quota definition'''
** Hard limit on the total space that the dataset and all its descendants (child datasets, snapshots, clones) can consume.
** A unit (MiB, GiB, TiB) can be selected from the drop-down.
* '''Include snapshots and clones''' (checkbox)
** When checked (default), space used by snapshots and clones counts towards the quota. This matches standard ZFS behaviour and is usually recommended.

Notes:

* Quota cannot be smaller than reservation (if reservation is enabled).
* When the quota is reached, further writes fail with “out of space” for this dataset even if the pool still has free capacity.

==== Enable reservation ====
When this switch is enabled:

* '''Reserved space'''
** Amount of pool space reserved exclusively for this dataset.
** You cannot reserve more than the currently available free space in the pool. The dialog shows the currently available physical space below the field.
* '''Include snapshots and clones''' (checkbox)
** When checked, the reserved space covers the dataset and all its descendants (snapshots and clones).
** When unchecked, reserved space applies only to the dataset itself (behaviour similar to ZFS refreservation).

Additional rules:

* The sum of all reservations in a pool cannot exceed its free space.
* Quota must be greater than or equal to reservation.

Use reservation only for datasets that must have guaranteed space, for example critical databases or backup targets.
[[Category:Help topics]]

Zpool wizard

2026-01-15T07:43:55Z

Da-F:

__NOTOC__
The '''Zpool Wizard''' guides you through the process of creating and configuring a new ZFS pool (zpool) from available disks. A zpool is the foundational storage construct in ZFS. It serves as a logical storage pool that combines multiple physical storage devices (disks) into '''vdevs''' (virtual devices), which collectively form the unified zpool. The wizard consists of multiple steps that allow you to configure data groups (vdevs), add optional device groups, adjust pool settings, and enable encryption if required.

== Accessing the wizard ==

#Navigate to '''Storage'''.
#Click '''Add zpool'''.
#The Zpool creation wizard will launch.
#Follow the guided steps to configure your zpool.

== Zpool configuration steps ==

=== Add data group  ===

In this step, available disks are listed. You can filter only unused disks using the toggle.

#Select one or more disks from the list.
#Choose the desired redundancy level for the group:
#*'''Single''' - No redundancy. Any disk failure results in data loss.
#*'''Mirror''' - Data is stored on multiple disks. Capacity equals the size of one disk per mirror.
#**'''Mirror (Single Group)''': All selected disks will be combined into a single mirrored group.
#**'''Mirror (Multiple Groups)''': The selected disks will be paired into multiple mirrored groups, each consisting of two disks.
#*'''Z-1''' - Single-parity redundancy. One disk may fail without losing data. A minimum of three disks is required for a RAIDZ-1 group.
#*'''Z-2''' - Double-parity redundancy. Two disks may fail without losing data. A minimum of four disks is required for a RAIDZ-2 group.
#*'''Z-3''' - Triple-parity redundancy. Three disks may fail without losing data. A minimum of five disks is required for a RAIDZ-3 group.
#Click '''Add group''' to add the selected configuration. 
#*The selected data group will appear in the right-hand panel. The total zpool capacity and licensed storage usage are displayed below. 
#*To learn more vdev types, please refer to the following article: [[Redundancy in Disks Groups|Redundancy in Disk Groups]] 

=== Add write log (optional) ===

This feature allows you to configure the write log function with a selected redundancy level (single drive or mirror). The write log utilizes a separate intent log (SLOG) device. A fast SSD/NVMe should be used for this vdev.

#Select disks from the available list.
#Choose redundancy type ('''Single''' or '''Mirror''') for added reliability.
#Add the group to the zpool.

Write log groups are displayed separately in the Other groups section.

'''Key points to consider''':

• If multiple log devices are specified, write operations are load-balanced between the devices.
• Log devices can be configured with redundancy by using mirrors to enhance fault tolerance.
• RAIDZ vdev types are not supported for the intent log.

This ensures efficient and reliable write operations while leveraging the selected redundancy level.

=== <br/>Add read cache (optional) ===

This step allows you to assign SSDs as L2ARC (Level 2 Adaptive Replacement Cache) devices to boost read performance. Adding a read cache improves performance and reduces latency for storage systems under heavy read load. A cache device stores frequently accessed data from the storage pool, providing an additional layer of caching between main memory and disk. These devices cannot be configured as mirrors or RAIDZ groups. A fast SSD/NVMe should be used for this vdev.

#Select a disk to be used as a cache device. Only '''Single''' redundancy is available.
#Confirm by adding the group.

<br/>'''Key benefits and considerations''':

• Cache devices are particularly useful for '''read-heavy workloads''' where the working dataset size exceeds the capacity of main memory.
• By utilizing cache devices, a larger portion of the working dataset can be served from low-latency storage, improving performance significantly.
• The greatest performance improvements are seen in workloads characterized by random reads of primarily static content.

=== <br/>Add special devices group (optional) ===

Special and deduplication vdevs require at least the same level of redundancy as data vdevs.
Because RAIDZ vdevs do not provide compatible redundancy for these device groups, special vdevs and deduplication vdevs cannot be used in a ZFS pool that contains RAIDZ1, RAIDZ2, or RAIDZ3.

A special devices group stores metadata and small-block data to improve performance. A fast SSD/NVMe should be used for this vdev.

#Select one or more disks.
#Choose redundancy ('''Single''' or '''Mirror'''). '''The mirror redundancy level is recommended to prevent data loss'''.
#Add them as a group.

<br/>'''Key features and benefits''':

• Storing metadata on special devices improves performance for metadata-intensive operations, such as file lookups and directory traversals.
• Small files below a certain size threshold can also be stored on these devices, enhancing read and write speeds for such workloads.
• Special devices are particularly beneficial for environments with a large number of small files or high metadata activity.

Using special devices optimizes the overall performance of the ZFS pool by offloading critical metadata and small-file operations to faster storage. 

=== Add deduplication group (optional) ===

A deduplication group can be explicitly excluded from a special device group to hold deduplication tables. This allows the deduplication tables to be stored separately from the special device class.

#Select disks for this purpose. Redundancy can be set to '''Single''' or '''Mirror'''. '''The mirror redundancy level is recommended to prevent data loss'''.
#Add the group to confirm.

<br/>'''Key features and considerations''':

• Storing deduplication tables in a dedicated group improves the efficiency of deduplication processes by isolating them from other metadata operations.
• This configuration provides flexibility in optimizing storage layout based on workload requirements.
• Using a deduplication group is particularly beneficial for systems with high deduplication demands, ensuring better performance and management.

This setup enhances deduplication performance while maintaining a clear separation of metadata and deduplication operations.

=== <br/>Add spare disks (optional) ===

A spare disk is a special pseudo-vdev used to track available spare devices for a zpool. Using spare disks enhances the storage pool's reliability by enabling seamless drive replacement and reducing the risk of data loss.

#Select the disk and add it to the '''Spare''' group.

=== Configuration ===

In this step, you configure the final pool settings:

*'''Zpool name''' - Enter a unique name for the zpool for easy identification.
*'''autoTRIM''' - If supported by your devices, enable the AutoTRIM feature to reclaim unused space automatically. AutoTRIM helps optimize SSD performance and lifespan by notifying the controller when blocks are no longer in use.
*'''Initialize the zpool after creation''' - Writes patterns to unallocated space to avoid initial-write latency, especially in virtualized environments. The process may extend creation time and briefly affect performance.

Proper configuration ensures that the Zpool is tailored to your needs and operates efficiently.

=== Resource encryption (optional) ===

Encryption applies to datasets and zvols created in the ZFS pool. The zpool itself remains unencrypted.

#Enable '''Configure encryption passphrase'''. 
#Select a '''Default encryption method'''. 
#Enter and confirm the passphrase.

Proper configuration ensures that the Zpool is tailored to your needs and operates efficiently.

'''Note''':
• The passphrase cannot be recovered.
• Encrypted resources inherit the passphrase unless changed later.

=== Summary ===

The summary page displays the complete zpool configuration before finalization. Click '''Add zpool''' to complete pool creation. The wizard will create the zpool with the selected configuration.

'''Remember''':
• Redundancy level cannot be changed after the ZFS pool is created.
• Mixed disk sizes reduce usable capacity to the smallest disk in a vdev.
• SSDs are recommended for write log, special devices, and deduplication groups.
• Encryption passphrases cannot be recovered.
[[Category:Help topics]]

Encryption

2026-01-14T11:51:33Z

Da-F: Created page with "__NOTOC__ Encryption protects data stored in datasets and zvols within a ZFS pool (zpool). The encryption feature is available for every zpool, but encrypted resources can be created only after you configure a pool-wide encryption passphrase. Key characteristics: *Encryption applies to datasets and zvols; the zpool itself is not encrypted. *All encrypted resources in one zpool share the same passphrase. *Datasets and zvols can only be encrypted during their creation. *..."

__NOTOC__
Encryption protects data stored in datasets and zvols within a ZFS pool (zpool). The encryption feature is available for every zpool, but encrypted resources can be created only after you configure a pool-wide encryption passphrase.

Key characteristics:

*Encryption applies to datasets and zvols; the zpool itself is not encrypted.
*All encrypted resources in one zpool share the same passphrase.
*Datasets and zvols can only be encrypted during their creation.
*You can later change the pool-wide encryption passphrase and the default encryption method.

Use encryption when you need at-rest data protection within a specific zpool.

== Configuring resource encryption ==

#Go to '''Storage'''.
#Select the zpool you want to configure.
#Open the '''Configuration''' tab.
#Expand the '''Resource encryption''' section.

You will see either the initial configuration fields or the current encryption status, depending on whether encryption was already configured or was configured during [[Zpool_wizard|zpool creation]]. When no passphrase is configured for a zpool, the '''Resource encryption''' section shows:

*'''Default encryption method''' – algorithm that is preselected in the drop-down list and used by default for new encrypted datasets and zvols in this zpool, if you do not choose a different method during resource creation.
*'''Encryption passphrase''' – shared passphrase used to unlock all encrypted resources in this zpool.
*'''Confirm passphrase''' – repeat the passphrase for verification.

Enter the passphrase twice, select the default method, and then click '''Save settings'''.

'''Important''': The passphrase cannot be recovered if it is lost. Without the passphrase, encrypted resources in this zpool cannot be accessed.

Once the passphrase is configured, you can start creating encrypted datasets and zvols in this zpool. More details on how to use encryption in resources can be found here:

*Create a new zvol for iSCSI Target
*Create a new zvol for FC Group
*Create a new dataset

'''Notes''':

*Encryption can be enabled only at creation time. Existing datasets and zvols cannot be switched to encrypted mode by editing their properties.
*To protect existing data that is currently unencrypted, you must:
**Create a new encrypted dataset or zvol.
**Copy or replicate data from the old resource to the new encrypted one.
**Remove the unencrypted original if it is no longer needed.

== Managing a zpool with configured resource encryption ==

When a passphrase is already configured, the '''Resource encryption''' section shows:

*'''Passphrase status''' (for example, configured).
*'''Default encryption method'''.
*Buttons:
**Change passphrase
**Change encryption method

=== Changing the encryption passphrase ===

#Click '''Change passphrase'''.
#In the dialog:
##Enter '''New passphrase'''.
##Confirm passphrase.
##Enter the '''Administrator''' password to authorize the change.
#Click '''Change passphrase'''.

After you confirm the change, the new passphrase is propagated to all existing encrypted datasets and zvols in the zpool. This synchronization may take some time, depending on the number of encrypted resources. A notification of the operation's start and completion is recorded in '''Event Viewer'''.

While the synchronization is in progress, the User Interface is locked for changes and cannot be used until the operation finishes.

=== Changing the default encryption method ===

#Click '''Change encryption method'''.
#Select a new '''Default encryption method''' from the drop-down list.
#Click '''Save method'''.

The selected method is displayed as default only for encrypted datasets and zvols created after this change. Existing encrypted resources keep their original encryption method which cannot be changed.

==== Available encryption methods ====

The following methods are available for resource encryption:

'''AES-128-CCM'''

*AES with a 128-bit key in CCM (Counter with CBC-MAC) mode.
*Provides authenticated encryption with moderate CPU usage.
*Suitable when you need a balance between performance and security.

'''AES-192-CCM'''

*AES with a 192-bit key in CCM mode.
*Higher security margin than 128-bit, with slightly higher CPU cost.
*Use when you prefer stronger keys and can accept a small performance impact.

'''AES-256-CCM'''

*AES with a 256-bit key in CCM mode.
*Maximum key length in the CCM group.
*Use when the security margin is more important than performance.

'''AES-128-GCM'''

*AES with a 128-bit key in GCM (Galois/Counter Mode).
*Authenticated encryption optimized for performance on modern CPUs.
*Good choice when you need strong encryption with high throughput.

'''AES-192-GCM'''

*AES with a 192-bit key in GCM mode.
*Increases key size over AES-128-GCM while remaining performant.
*Use when you want a higher security margin but similar behavior to AES-128-GCM.

'''AES-256-GCM'''

*AES with a 256-bit key in GCM mode.
*Provides strong authenticated encryption and is widely used as a best-practice choice.
*Recommended default when your hardware can handle the additional CPU load.

== Handling invalid or missing passphrase ==

If the encryption passphrase is invalid or not configured on the current host, all encrypted datasets and zvols in the affected zpool are locked and cannot be accessed. When a locked zvol is attached to an iSCSI target, FC group, or NVMe-oF subsystem, these objects are effectively blocked as well, and no data can be accessed through them. For an encrypted dataset, all shares configured on it are also blocked.

To restore access, enter the correct passphrase in '''Configuration → Resource encryption''' for the zpool. After a valid passphrase is provided, all locked, encrypted resources are automatically unlocked and become active again, provided that the related targets, groups, subsystems, or datasets were not manually deactivated beforehand.

Such situations may occur, for example, when a zpool is imported on a different host or moved between cluster nodes. In a cluster environment, the passphrase is usually synchronized between nodes, so after a failover, the other node already has the required passphrase. However, if the passphrase change operation was interrupted, some encrypted resources may have been updated to the new passphrase while others still use the old one. On the original host, access may still work, but after exporting the zpool and importing it on another host, some or all encrypted resources can become partially locked. In this case, an event is recorded in the Event Viewer indicating that the passphrase change did not complete successfully.

If this happens, first try to unlock the resources by entering the latest passphrase (the one you intended to change to). If this does not unlock all encrypted resources, enter the previous passphrase (the one used before the change), allow the passphrase change process to complete, and then change the passphrase again to the desired new value. This sequence should unify the passphrase across all encrypted resources in the zpool. Always monitor Event Viewer logs when working with encrypted resources and when changing passphrases.
[[Category:Help topics]]

NVMe-oF Initiator

2025-10-31T11:51:11Z

Da-F:

__NOTOC__
The NVMe-oF (NVMe over Fabrics) initiator enables connections to external NVMe storage arrays (targets) via network protocols. This feature provides efficient and high-performance management of remote storage solutions, overcoming traditional cabling limitations by allowing substantial distances between servers and storage arrays.

== Supported Protocols ==

The software supports two principal NVMe-oF initiator protocols:

*'''TCP''' – A widely adopted protocol ensuring ease of implementation and compatibility with conventional networking infrastructure.
*'''RDMA''' – A protocol providing lower latency and higher performance, ideal for environments requiring exceptional throughput. RDMA requires specialized hardware, such as Mellanox/NVIDIA ConnectX or ATTO network interface cards, to fully utilize its capabilities.

== Configuration ==

Follow these steps to configure the NVMe-oF initiator:

#'''Start Discovery'''
#;Click the "'''Discover'''" button to start the discovery wizard.
#'''Enter Connection Details'''
#*'''Server IP''': IP address of the NVMe storage target.
#*'''Server port''': Network port for communication ('''default is 4420''').
#*'''Server protocol''': Choose between TCP and RDMA.
#*'''Advanced settings (optional)''': Enable and specify the number of I/O queues. Leave blank or disabled to use the system default, or enter a specific number to override.
#:The number of I/O queues refers to the parallel channels through which data is transferred between the NVMe initiator and the target. Increasing this number can improve performance by enabling higher parallelism and reducing latency. However, each queue consumes system resources, and setting the number too high may exceed hardware or network capabilities, leading to connection issues. Adjust this value based on performance requirements and available resources.
#'''Proceed to Subsystems'''
#;Click "'''Next'''". A list of available NVMe-oF subsystems will appear. Select the subsystems you want to connect to and click “'''Connect'''”.

== Manage Connection Paths ==

'''Add a new path''': Click the “'''Options'''” dropdown menu and select “'''Add path'''”. Enter the required connection details (Server IP, port, protocol, and optionally the number of I/O queues).

'''Disconnect a subsystem''': Use the “'''Options'''” menu and select “'''Disconnect subsystem'''”.

You can perform additional discoveries at any time to connect new subsystems.

== Practical Implementation ==

After connecting to a subsystem, a list of available namespaces will be displayed, including:

*Namespace ID
*Namespace capacity
*Namespace aliases

Namespaces are sections of the NVMe controller on the storage array. They appear as independent NVMe disks to the server, can be identified by their alias, and are managed in the same manner as standard NVMe disks. Namespaces can be partitioned and added to storage pools.

'''Note''': Only one partition per disk can be active within a single pool or data group to maintain redundancy and reliability.

== Multi-path Connectivity ==

The initiator supports multi-path connectivity, allowing multiple redundant network paths to a single NVMe target. Each path requires a distinct IP address (Virtual IP) to ensure redundancy and high availability.

== Troubleshooting ==

If you encounter connection issues (e.g., “Could not connect to subsystem(s)” error), consider the following actions:

#Check Network Connectivity:
#*Ensure that the server can ping the target’s IP address.
#*Verify that the correct port (default 4420) is open and not blocked by a firewall.
#Validate Target Configuration:
#*Verify that the NVMe target is online and properly configured to support NVMe over Fabrics (NVMe-oF) connections.
#*Ensure that access control lists (ACLs) or authentication settings on the target allow the initiator to establish a connection.
#Adjust I/O Queues:
#*If connection errors occur due to queue limits, try lowering the number of I/O queues in the advanced settings to match target capabilities.
#Use Alternative Paths:
#*If multiple network interfaces are available (typical in JBOD or HA environments), try using an alternative IP address or configure multi-path connectivity.
#Review Logs:
#*Check logs for detailed error messages that can guide further troubleshooting.

[[Category:Help topics]]

System volume upgrade

2025-10-31T10:51:43Z

Da-F: Created page with "__NOTOC__ '''Note''': This upgrade improves system stability and performance but is irreversible. Pools upgraded to a 64 KB system volume volblocksize cannot be accessed by o..."

__NOTOC__
'''Note''': This upgrade improves system stability and performance but is irreversible. Pools upgraded to a 64 KB system volume volblocksize cannot be accessed by older software versions.

After installing a software version that supports the latest ZFS file system, you may be prompted to upgrade the system volume on each storage pool. This operation improves stability and performance by setting the system volume's volblocksize to '''64 KB'''.

== Upgrade Notification ==

When a pool uses an older system volume format, an information banner appears in the Storage view. It recommends performing the upgrade and specifies the required free space - '''8 GB''' on the pool. To begin, open the '''Options''' menu for the selected pool, then select ''''Upgrade system volume''''.

== Upgrade Process ==

#A confirmation window appears, displaying a warning that the operation cannot be undone. For safety, please type the word ''''upgrade'''' into the confirmation field.
#Click '''Upgrade''' to start the process.
#A progress window is shown during the upgrade.
#When completed, a message appears indicating that the system volume has been upgraded to 64 KB. To finalize, you must '''export and import''' the pool or use the '''Move''' option if the pool belongs to a cluster.

== After Upgrade ==

Once the system volume has been successfully updated, the pool’s status panel displays a message indicating that a '''pool export/import''' is required to complete the process. After performing this step, the system volume upgrade is fully applied.

Active Directory (AD) server authentication

2025-10-16T13:32:46Z

Da-F:

__NOTOC__
This functionality is available in '''User Management > Share users/groups > Authorization protocols'''.

<br/>To configure a connection to the existing Active Directory server:

#Navigate to the '''User Management '''section in the left menu.
#Go to the '''Share users/groups''' tab.
#Find the '''Active Directory (AD) server authentication''' block.
#Enable the '''Enable protocol''' option.

== AD server authentication status ==

*'''Connection''' - shows whether you are connected to an AD server or not.
*'''Users/groups list''' - shows when the lists of users and groups were last synchronized or if the synchronization is taking place at the moment.

Users and groups are synchronized with an Active Directory server every 2 hours. Synchronization can also be started manually by using the '''Synchronize''' button.

== AD server authentication settings ==

To connect to the existing AD server, fill in the following fields with credentials provided by the AD server administrator and click the '''Apply''' button.

*'''Realm'''
*'''Administrator name'''
*'''Password'''<br/>NOTE''': Password cannot contain:'''
**special characters such as ' " ` ^ & $ # ~ [ ] \ / | * : ? < >
**spaces
**less than 12 and more than 16 characters
*'''Organizational Unit (OU) - '''a direct path to the container where the Computer Organizational Unit is placed. The path must be entered starting from the primary container name within the domain structure. The container name set by default is '''Computers'''. If another container name is used instead, then '''Computers''' must be changed to the appropriate name. If the path to the container is nested, use a slash as the connector. In the screenshot below, the OU is in the '''Computers''' container that is nested in '''AllComputers > Marketing'''. In this example, the path to the OU is: '''AllComputers/Marketing/Computers'''<br/><br/>[[File:Ad-structure.png]]<br/><br/>NOTE''': Container name can't contain:'''
**special characters such as , + " \ < > ; = / #
**spaces

<div>'''The following reasons might prevent you from connecting to Active Directory:'''<br/></div>
#Difference in time between Active Directory Server - if the time difference is greater than 5 minutes, the connection is not possible.
#The method of authenticating trusted domains - the authentication has to be set to two-way trust. Otherwise, it is not possible to read users and groups from trusted domains.
#DNS configuration - for an Active Directory domain, it is not possible to use a round-robin mechanism in DNS. This is connected to the fact that only one IP address is authorized. In a moment when another IP is obtained from DNS, the connection is not possible.
#The '''server name''' is the same as the Computer Organizational Unit (OU) named in the Active Directory (AD) server. If the object with the same name exists and the user that you use to log in to the AD server does not have permission to access this file, the connection will fail. The solution is to delete the existing computer object from the AD server. The following information explains how to delete the OU file:
<ul style="margin-left: 80px;">
<li>Log on to the Domain Controller with the domain administrator account. Press Windows Logo + R, enter "dsa.msc" and press Enter.</li>
<li>In the "Active Directory Users and Computers" window, select the domain container in which the OU you are looking for is located.</li>
<li>Select the computer object and delete it.</li>
</ul>

::'''Note''': By default, any created Organizational Unit is protected from accidental deletion. To delete the OU, you need to clear the "Protect object from accidental deletion" checkbox, which you can find in the object properties in the "Object" tab. By deleting OU, you delete all nested objects that it contains as well.
:::<div><br/></div>

== Users and user groups management ==

'''Management mode:'''

*'''Scan single domain (default)''' - Using this function allows the user to obtain users and groups from the main domain only.

*'''Scan all trusted domains''' - Using this function allows the user to obtain users and groups from the main and trusted domains.

<br/>'''ID mapping backend:'''

*'''rid + tdb (default)''' - This option utilizes the rid backend for ID mapping to AD users. UID/GIDs range has to be entered manually The tdb backend is used when no other configuration is set. Recommended for large databases.Samba Wiki link for rid backend: [https://wiki.samba.org/index.php/Idmap_config_rid https://wiki.samba.org/index.php/Idmap_config_rid]
*'''ad (with RFC2307 schema) + tdb''' - Allows reading ID mappings from an AD server, provided that the uidNumber attributes for users and gidNumber attributes for groups were added in advance in the AD. This backend requires additional configuration of uidNumber and gidNumber on the AD server side. The tdb back end is used when no other configuration is set. Samba Wiki link for rid backend: [https://wiki.samba.org/index.php/Idmap_config_ad https://wiki.samba.org/index.php/Idmap_config_ad]
*'''autorid''' - Automatically configures the range to be used for each domain. The only configuration needed is the range of UID/GIDs used for user/group mappings and the number of IDs per domain. Samba Wiki link for autorid backend: [https://wiki.samba.org/index.php/Idmap_config_autorid https://wiki.samba.org/index.php/Idmap_config_autorid]

Autorid is not recommended in cluster environments.

== Troubleshooting ==

'''<span style="font-size:small">The TDB UID/GIDs mapping does not work properly.</span>'''

'''Single-Domain Environments'''
<div>It is recommended to use the "autorid" option in the "ID mapping backend" settings. Alternatively, you can use the "rid+tdb" option. If you choose "rid+tdb," set the UID/GIDs mapping to "rid" and define the Min ID and Max ID range (e.g., 2,000,000 to 2,999,999). The range 1,000,000 to 1,999,999 is reserved.</div><br/>
'''Multi-Domain Environments'''
<div>The "autorid" option cannot be used. Instead, use "rid+tdb" or "ad (with RFC2307 schema) + tdb." Ensure the UID/GIDs mapping is set to "rid" and define the Min ID and Max ID range for each domain (e.g., 2,000,000 to 2,999,999 for the first domain, 3,000,000 to 3,999,999 for the second domain, etc.).</div>
[[Category:Help topics]]

NVMe-oF Initiator

2025-07-30T12:28:32Z

Da-F:

NVMe-oF discover

2025-07-30T12:09:57Z

Da-F: Redirected page to NVMe-oF Initiator

#REDIRECT[[NVMe-oF Initiator]]

NVMe-oF Subsystem Connection Problems

2025-07-30T11:29:08Z

Da-F: Redirected page to NVMe-oF Initiator

#REDIRECT[[NVMe-oF Initiator]]

NVMe-oF Subsystems

2025-07-30T10:31:48Z

Da-F: Redirected page to NVMe-oF Initiator

#REDIRECT[[NVMe-oF Initiator]]

NVMe-oF Initiator

2025-07-30T10:07:14Z

Da-F:

NVMe-oF Initiator

2025-07-30T10:05:00Z

Da-F:

__NOTOC__
The NVMe-oF (NVMe over Fabrics) initiator enables connections to external NVMe storage arrays (targets) via network protocols. This feature provides efficient and high-performance management of remote storage solutions, overcoming traditional cabling limitations by allowing substantial distances between servers and storage arrays.

== Supported Protocols ==

The software supports two principal NVMe-oF initiator protocols:

*'''TCP''' – A widely adopted protocol ensuring ease of implementation and compatibility with conventional networking infrastructure.
*'''RDMA''' – A protocol providing lower latency and higher performance, ideal for environments requiring exceptional throughput. RDMA requires specialized hardware, such as Mellanox/NVIDIA ConnectX or ATTO network interface cards, to fully utilize its capabilities.

== Configuration ==

Follow these steps to configure the NVMe-oF initiator:

#'''Start Discovery'''
#;Click the "'''Discover'''" button to start the discovery wizard.
#'''Enter Connection Details'''
#:The number of I/O queues refers to the parallel channels through which data is transferred between the NVMe initiator and the target. Increasing this number can improve performance by enabling higher parallelism and reducing latency. However, each queue consumes system resources, and setting the number too high may exceed hardware or network capabilities, leading to connection issues. Adjust this value based on performance requirements and available resources.
#*'''Server IP''': IP address of the NVMe storage target.
#*'''Server port''': Network port for communication ('''default is 4420''').
#*'''Server protocol''': Choose between TCP and RDMA.
#*'''Advanced settings (optional)''': Enable and specify the number of I/O queues. Leave blank or disabled to use the system default, or enter a specific number to override.
#'''Proceed to Subsystems'''
#;Click "'''Next'''". A list of available NVMe-oF subsystems will appear. Select the subsystems you want to connect to and click “'''Connect'''”.

== Manage Connection Paths ==

'''Add a new path''': Click the “'''Options'''” dropdown menu and select “'''Add path'''”. Enter the required connection details (Server IP, port, protocol, and optionally the number of I/O queues).

'''Disconnect a subsystem''': Use the “'''Options'''” menu and select “'''Disconnect subsystem'''”.

You can perform additional discoveries at any time to connect new subsystems.

== Practical Implementation ==

After connecting to a subsystem, a list of available namespaces will be displayed, including:

*Namespace ID
*Namespace capacity
*Namespace aliases

Namespaces are sections of the NVMe controller on the storage array. They appear as independent NVMe disks to the server, can be identified by their alias, and are managed in the same manner as standard NVMe disks. Namespaces can be partitioned and added to storage pools.

'''Note''': Only one partition per disk can be active within a single pool or data group to maintain redundancy and reliability.

== Multi-path Connectivity ==

The initiator supports multi-path connectivity, allowing multiple redundant network paths to a single NVMe target. Each path requires a distinct IP address (Virtual IP) to ensure redundancy and high availability.

== Troubleshooting ==

If you encounter connection issues (e.g., “Could not connect to subsystem(s)” error), consider the following actions:

#Check Network Connectivity:
#*Ensure that the server can ping the target’s IP address.
#*Verify that the correct port (default 4420) is open and not blocked by a firewall.
#Validate Target Configuration:
#*Verify that the NVMe target is online and properly configured to support NVMe over Fabrics (NVMe-oF) connections.
#*Ensure that access control lists (ACLs) or authentication settings on the target allow the initiator to establish a connection.
#Adjust I/O Queues:
#*If connection errors occur due to queue limits, try lowering the number of I/O queues in the advanced settings to match target capabilities.
#Use Alternative Paths:
#*If multiple network interfaces are available (typical in JBOD or HA environments), try using an alternative IP address or configure multi-path connectivity.
#Review Logs:
#*Check logs for detailed error messages that can guide further troubleshooting.

NVMe-oF Initiator

2025-07-30T10:02:48Z

Da-F: Created page with "__NOTOC__ The NVMe-oF (NVMe over Fabrics) initiator enables connections to external NVMe storage arrays (targets) via network protocols. This feature provides efficient and hi..."

__NOTOC__
The NVMe-oF (NVMe over Fabrics) initiator enables connections to external NVMe storage arrays (targets) via network protocols. This feature provides efficient and high-performance management of remote storage solutions, overcoming traditional cabling limitations by allowing substantial distances between servers and storage arrays.

== Supported Protocols ==

The software supports two principal NVMe-oF initiator protocols:

*'''TCP''' – A widely adopted protocol ensuring ease of implementation and compatibility with conventional networking infrastructure.
*'''RDMA''' – A protocol providing lower latency and higher performance, ideal for environments requiring exceptional throughput. RDMA requires specialized hardware, such as Mellanox/NVIDIA ConnectX or ATTO network interface cards, to fully utilize its capabilities.

== Configuration ==

Follow these steps to configure the NVMe-oF initiator:

#'''Start Discovery'''
#;Click the "'''Discover'''" button to start the discovery wizard.
#'''Enter Connection Details'''
#:The number of I/O queues refers to the parallel channels through which data is transferred between the NVMe initiator and the target. Increasing this number can improve performance by enabling higher parallelism and reducing latency. However, each queue consumes system resources, and setting the number too high may exceed hardware or network capabilities, leading to connection issues. Adjust this value based on performance requirements and available resources.
#*'''Server IP''': IP address of the NVMe storage target.
#*'''Server port''': Network port for communication ('''default is 4420''').
#*'''Server protocol''': Choose between TCP and RDMA.
#*'''Advanced settings (optional)''': Enable and specify the number of I/O queues. Leave blank or disabled to use the system default, or enter a specific number to override.

'''Proceed to Subsystems'''

;Click "'''Next'''". A list of available NVMe-oF subsystems will appear. Select the subsystems you want to connect to and click “'''Connect'''”.
;<br/>

== Manage Connection Paths ==

'''Add a new path''': Click the “'''Options'''” dropdown menu and select “'''Add path'''”. Enter the required connection details (Server IP, port, protocol, and optionally the number of I/O queues).

'''Disconnect a subsystem''': Use the “'''Options'''” menu and select “'''Disconnect subsystem'''”.

You can perform additional discoveries at any time to connect new subsystems.

== Practical Implementation ==

After connecting to a subsystem, a list of available namespaces will be displayed, including:

*Namespace ID
*Namespace capacity
*Namespace aliases

Namespaces are sections of the NVMe controller on the storage array. They appear as independent NVMe disks to the server, can be identified by their alias, and are managed in the same manner as standard NVMe disks. Namespaces can be partitioned and added to storage pools.

'''Note''': Only one partition per disk can be active within a single pool or data group to maintain redundancy and reliability.

== Multi-path Connectivity ==

The initiator supports multi-path connectivity, allowing multiple redundant network paths to a single NVMe target. Each path requires a distinct IP address (Virtual IP) to ensure redundancy and high availability.

== Troubleshooting ==

If you encounter connection issues (e.g., “Could not connect to subsystem(s)” error), consider the following actions:

#Check Network Connectivity:
#*Ensure that the server can ping the target’s IP address.
#*Verify that the correct port (default 4420) is open and not blocked by a firewall.
#Validate Target Configuration:
#*Verify that the NVMe target is online and properly configured to support NVMe over Fabrics (NVMe-oF) connections.
#*Ensure that access control lists (ACLs) or authentication settings on the target allow the initiator to establish a connection.
#Adjust I/O Queues:
#*If connection errors occur due to queue limits, try lowering the number of I/O queues in the advanced settings to match target capabilities.
#Use Alternative Paths:
#*If multiple network interfaces are available (typical in JBOD or HA environments), try using an alternative IP address or configure multi-path connectivity.
#Review Logs:
#*Check logs for detailed error messages that can guide further troubleshooting.

JBODs & JBOFs

2025-04-29T09:09:52Z

Da-F:

This functionality is available in the '''Storage Settings > JBODs & JBOFs''' tab

It’s used to obtain more information about the disks in the JBOD or JBOF by using external services, e.g. Redfish. For this reason, it is dedicated to disks enclosures with out-of-band management.<br/>'''The functionality only works on currently supported devices such as SUPERMICRO SSG-136R-N32JBF.'''

In the case of SUPERMICRO SSG-136R-N32JBF, the Redfish service is used to gain more information about disks, so an account with this service will be needed. To link an enclosure to the service, click on the "'''Add device'''" button. A pop-up with a form will appear. Fill in the form.

To link a device through the service, the following information must be provided:

*'''Name (alias)''' - Set a name for the enclosure that allows the device to be recognized should there be a few machines of the same model.
*'''IP address / domain''' - The domain name or IP address connecting the device to the network.
*'''Port''' - Enter the number of the port used to communicate with the device through the Redfish service. The default port number is 443. Change as needed.
*'''Username''' - Enter the username to the Redfish service.
*'''Password''' - Enter the password that’s associated with the user name that’s been entered above.

After filling in every field, click the "'''Add'''" button. The system will then connect to the service and start to scan all the available disks. This may take some time. The system needs a while to scan a disk. Thus the more disks there are in an enclosure, the more time is needed to scan them all. After all the disks are scanned, the information will be available in the disk details section. Additional data such as:

*Name of the enclosure in which the disk is located,
*Number of the slot in which the disk is located

will also be displayed generally (i.e., in pool's disk groups, pool wizard, etc.).

'''NOTE!''' When the connection status changes, a rescan of all disks is required. This occurs, e.g.:

*When a device configuration is changing,
*When the system is restarted,
*After network reconnection (when the connection has been lost), etc.

The connection status of the enclosure is displayed in the table in the "'''JBODs & JBOFs'''" tab at all times. Next to the connection status there’s a power state displayed that shows if the device is turned on.<br/>Every device that has been added can be edited, removed from the table, or selected to display its details.

To do any of the above, use the context menu.<br/>The “'''Edit'''” option allows changing the device’s data or credentials.<br/>The “'''Details'''” option shows more information about an enclosure such as:

*Name (alias)
*Model
*Vendor name

The “'''Remove'''” option leads to the removal of a device from the table. Removing a device causes it to disconnect from the external service. Any additional information uploaded via the service after removing a device will not be displayed. In some cases, the option to turn on the LED for disks in the JBOD/JBOF may also become disabled.

[[Category:Help topics]]

NFS service

2025-02-26T13:06:47Z

Da-F:

With this function you can enable/disable Network File System (NFS) service and set NFS threads count. If you have a large number of clients accessing this NFS server and they experience some amount of lag in their operations, you can try to increase the threads count number. Enable NFS VAAI support Speeds up virtual machine cloning by offloading copy/clone operations to the storage backend. Requires virtual machine to be powered off.

[[Category:Help topics]]

Open-E JovianDSS ver.1.0 up31 ZFS Upgrade

2025-01-21T07:43:46Z

Da-F: Redirected page to File system upgrade

#REDIRECT [[File system upgrade]]

IDs range conflict within the cluster

2025-01-20T14:23:09Z

Da-F: Created page with "<div>In a clustered environment connected to an Active Directory (AD) server, user IDs (UIDs) and group IDs (GIDs) must remain consistent across all nodes. However, using the ..."

<div>In a clustered environment connected to an Active Directory (AD) server, user IDs (UIDs) and group IDs (GIDs) must remain consistent across all nodes. However, using the autorid backend for mapping IDs can create problems during failover. When one node fails and another takes over, autorid may map user IDs differently, causing users to lose access to shared files and folders.</div><div>If the system detects that different ID ranges are assigned to the same AD domain across cluster nodes, it will display the warning: '''"ID range conflict within the cluster."'''</div>
== Steps to resolve the problem ==
<div>Follow these steps to resolve the issue and ensure consistent ID mappings across the cluster:</div>
#'''Identify the node with correct mapping''':<br/>Log in to the node where user access is working correctly and user IDs are mapped as expected.
#'''Change the ID mapping backend''':<br/>Update the ID mapping backend from autorid to rid+tdb. The rid+tdb backend assigns IDs based on the relative identifier (RID) from the AD, ensuring the same IDs are used across all cluster nodes, while also allowing for dynamic ID assignment through the tdb backend for greater flexibility. <u>'''Don't change the tdb backend ranges to keep the UID/GIDs ranges assigned to domains so far'''</u>.
#'''Synchronize settings across nodes''':<br/>After switching the backend, the ID settings from the updated node will automatically synchronize with the other node in the cluster.
#'''Verify and check configuration''':<br/>Check that users can still access their files and folders. Perform a failover test to confirm that permissions remain correct when a node takes over.

== Why use the rid+tdb backend? ==
<div>Switching to the rid+tdb backend provides a reliable and predictable way to map IDs across nodes, avoiding conflicts caused by the dynamic ID assignment of autorid. It is a proven solution for maintaining stable user ID mappings in clustered environments.</div>

File system upgrade

2025-01-16T10:22:50Z

Da-F:

<div>After upgrading to a version with a newer ZFS filesystem, the following notification will be displayed upon first access:</div><br/>
<q>Zpools available for ZFS filesystem upgrade Upgrading Zpools to the latest ZFS file system is recommended. Although the file system upgrade is absolutely safe for your data and its integrity and will only take few minutes please be aware that this operation cannot be undone and accessing this zpool data will not be possible with older software versions. In order to upgrade a single Zpool, please use “Upgrade file system" from Zpool's option menu.</q>
<br/><div>Additionally, the zpool itself will display the following zpool status:</div><br/>
<q>Some supported features are not enabled on the pool. The pool can still be used but it is recommended to upgrade it in order to fully utilize all system features. Action: Upgrade the pool using "Upgrade file system" in pool options menu. Once this is done, the pool will no longer be accessible by software that does not support new features.</q>
<br/><div>As prompted, expand the zpool options and choose "Upgrade file system":</div>
[[File:Upgrade file system option.png]]
<br/><div>The following windows will appear. Type ‘upgrade’ and click the Upgrade button to proceed:</div>
[[File:Upgrade file system confirmation.png]]
<br/><div>Once completed, the system will notify you that the zpool has been updated successfully.</div>
[[Category:Help topics]]

File system upgrade

2025-01-16T10:20:46Z

Da-F: Created page with "<div>After upgrading to a version with a newer ZFS filesystem, the following notification will be displayed upon first access:</div><br/> <q>Zpools available for ZFS filesyste..."

<div>After upgrading to a version with a newer ZFS filesystem, the following notification will be displayed upon first access:</div><br/>
<q>Zpools available for ZFS filesystem upgrade Upgrading Zpools to the latest ZFS file system is recommended. Although the file system upgrade is absolutely safe for your data and its integrity and will only take few minutes please be aware that this operation cannot be undone and accessing this zpool data will not be possible with older software versions. In order to upgrade a single Zpool, please use “Upgrade file system" from Zpool's option menu.</q>
<br/><div>Additionally, the zpool itself will display the following zpool status:</div><br/>
<q>Some supported features are not enabled on the pool. The pool can still be used but it is recommended to upgrade it in order to fully utilize all system features. Action: Upgrade the pool using "Upgrade file system" in pool options menu. Once this is done, the pool will no longer be accessible by software that does not support new features.</q>
<br/><div>As prompted, expand the zpool options and choose "Upgrade file system":</div>
[[File:Upgrade file system option.png]]
<br/><div>The following windows will appear. Type ‘upgrade’ and click the Upgrade button to proceed:</div>
[[File:Upgrade file system confirmation.png]]
<div>Once completed, the system will notify you that the zpool has been updated successfully.</div><div>[[Category:Help_topics]]</div>

File:Upgrade file system confirmation.png

2025-01-16T10:18:50Z

Da-F:

File:Upgrade file system option.png

2025-01-16T10:18:40Z

Da-F:

Redundancy in Disks Groups

2025-01-15T15:02:51Z

Da-F:

__NOTOC__
Disk group redundancy refers to the ability of a zpool to maintain data integrity and availability in the event of disk failures. This is achieved through mirrored or RAID-Z configurations, which store multiple copies of data across different disks. When a disk fails or data corruption is detected, ZFS can use the redundant copies to repair or reconstruct the lost data, ensuring the system continues to operate without data loss.

It is important not to mix the types of data groups (vdevs) inside your storage zpool, as it might lead to potential issues, so it is strongly recommended to consistently use only one type of vdev.

== <br/>Data Group redundancy level: 2-way mirror (2 disks per group) ==

*The chances of suffering multiple disk failures increase with the number of mirror vdevs in the zpool.
*The 2-way mirror accepts a single disk failure in a given vdev.
*The 2-way mirrors can be used for mission critical applications, but it is recommended not to exceed 12 vdevs in a zpool (recommended up to 12 x 2 = 24 disks for mission-critical applications and 24 x 2 = 48 disks for non-mission critical applications in a zpool).
*'''Note''': as a rule, the zpool performance increases with the number of vdevs in the pool. For mission-critical applications and using more than 12 groups, It is recommended to use 3-way mirrors or RAID-Z2 or RAID-Z3.
*For mission critical applications it is not recommended to use HDDs bigger than 4TB.

== Data Group redundancy level: 3-way mirror (3 disks per group) ==

*The chances of suffering multiple disk failures increase with number of mirror vdevs in the zpool.
*The 3-way mirror accepts up to two disks failures in a given vdev.
*3-way mirrors can be used for mission critical applications, but it is recommended not to exceed vdevs in a zpool (recommended up to 16 x 3 = 48 disks for mission critical applications and 24 x 3 = 72 disks for non-mission critical applications in a zpool).
*'''Note''': the zpool performance increases with the number of vdevs in a zpool. For mission-critical applications, it is recommended to use RAID-Z3.
*For mission critical applications it is not recommended to use HDDs bigger than 10TB.

== Data Group redundancy level: 4-way mirror (4 disks per group) ==

*The chances of suffering multiple disk failures increase with number of mirror vdevs in the zpool.
*The 4-way mirror accepts up to three disks failures in a given vdev.
*The 4-way mirror is recommended for a Non-Shared HA Cluster that can be used for mission-critical applications.
*It is also recommended not to exceed 24 of 4-way mirror vdevs in a zpool as a single group damage results in the destruction of the entire zpool (recommended up to 24 x 4 = 96 disks for mission-critical applications in a zpool).
*'''Note''': as a rule, the zpool performance increases with the number of vdev in the pool.
*HDDs bigger than 16TB should be avoided for mission critical applications.

== Data Group redundancy level: RAIDZ-1 (3-8 disks in a group) ==

*The chances of suffering multiple disk failures increase with the number of disks in a RAID-Z1 vdev.
*RAID-Z1 accepts one disk failure in a given vdev.
*The RAID-Z1 can be used for non-mission critical applications and it is not recommended to exceed 8 disks in a vdev. HDDs bigger than 4TB should be avoided.
*It is also not recommended to exceed 8 RAID-Z1 vdevs in a zpool as a single group damage results in the destruction of entire zpool (recommended up to 8 x 8 = 64 disks for non-mission critical applications in a zpool).
*RAID-Z1 configuration is not possible in a Non-Shared HA Cluster configuration.
*'''Note''': the zpool performance is doubled with 2 x RAID-Z1 with 4 disks each comparing to a single RAID-Z1 vdev with 8 disks.

== <br/>Data Group redundancy level: RAIDZ-2 (4-24 disks per group) ==

*The chances of suffering multiple disk failures increase with the number of disks in the RAID-Z2 group.
*The RAID-Z2 accepts up to two disks failures in a given vdev.
*The RAID-Z2 can be used for mission-critical applications.
*It is not recommended to exceed 12 disks in a vdev for mission-critical and 24 disks for non-mission critical applications.
*It is also not recommended to exceed 16 of RAID-Z2 groups in a zpool as a single group damage results in the destruction of the entire zpool (recommended up to 16 x 12 = 192 disks for mission-critical applications and 16 x 24 = 384 disks for non-mission critical in a zpool). HDDs bigger than 16 TB should be avoided.
*If 3 disks failure in a vdev is required, it is recommended to use RAID-Z3.
*RAID-Z2 configuration is not possible in a Non-Shared HA Cluster configuration.
*'''Note''': the pool performance is doubled with 2 x RAID-Z2 with 6 disks each comparing to a single RAID-Z2 with 12 disks.

== <br/>Data Group redundancy level: RAIDZ-3 (5-48 disks per group) ==

*The chances of suffering multiple disk failures increase with the number of disks in the RAID-Z3 group.
*The RAID-Z3 accepts up to three disks failure in a given vdev.
*The RAID-Z3 can be used for mission-critical applications.
*It is not recommended to exceed 24 disks in a vdev for mission-critical and 48 disks for non- mission critical applications.
*It is also not recommended to exceed 24 of RAID-Z3 groups in a zpool as a single group damage results in the destruction of the entire zpool (recommended up to 24x 24 =576 disks for mission critical applications and 24x 48 = 1152 disks for non-mission critical applications in a zpool). HDDs bigger than 16TB should be avoided.
*RAID-Z3 configuration is not possible in a Non-Shared HA Cluster configuration.
*'''Note''': the zpool performance is doubled with 2 x RAID-Z3 with 12 disks each comparing to single RAID-Z3 vdev with 24 disks.

== Write Log redundancy level ==

*In both single nodes and HA clusters, it should be configured as a 2-way mirror.
*When choosing a disk model for the Write Log, make sure to take the endurance parameter into consideration. Selecting a disk classified by the manufacturer as write intensive is strongly recommended.
*When selecting a disk size for the write log, consider the potential amount of data that’ll be able to reach the server in three consecutive ZFS transactions, e.g. based on the network card bandwidth for the data transfer. If the transaction length is set to 5 seconds (default), the write log device should be able to accommodate the amount of data that can be transferred within three transaction groups, i.e. 15 seconds of writing. Using a larger disk does not make sense economically, while a smaller one can be a performance bottleneck during synchronous writes. '''Practically speaking, 100GB for a write log should be more than enough.'''

== Read Cache redundancy level ==

Read Cache disks can only be configured as single disks, but it is possible to configure any number of them. In an HA cluster, Read Cache can only be configured as local disks on both nodes on the cluster.

== Special devices and deduplication group redundancy level ==

In both single nodes and HA clusters, it should be configured as a 2-way mirror.

[[Category:ZFS and data storage articles]]

Zpool wizard

2025-01-15T15:02:22Z

Da-F:

<div>A '''zpool''' is the foundational storage construct in ZFS. It serves as a logical storage pool that combines multiple physical storage devices (disks) into '''vdevs''' (virtual devices), which collectively form the unified zpool. From this zpool, ZFS creates and manages '''datasets''' (file systems) and '''zvols''' (block storage volumes).</div><br/><div>The zpool wizard is made up of the following steps:</div><br/><div>
<span style="font-size:larger">'''1. Add data group'''</span>

This section provides information about all storage devices connected to the storage server. To add the first Data Group to your Zpool, follow these steps:

#Select the desired disks from the list on the left.
#Choose the redundancy type.
#Click the "Add group" button.
</div><br/><div>The available redundancy options for groups are as follows:
*'''Single''': Each disk operates as an independent drive with no redundancy.
*'''Mirror''': All data written to one device in the mirror is automatically replicated to another device, ensuring data redundancy. A minimum of two disks is required to create a mirrored vdev.
**'''Mirror (Single Group)''': All selected disks will be combined into a single mirrored group.
**'''Mirror (Multiple Groups)''': The selected disks will be paired into multiple mirrored groups, each consisting of two disks.
*'''RAIDZ-1''': Allows for the failure of one disk per RAIDZ-1 group without losing data. A minimum of three disks is required for a RAIDZ-1 group.
*'''RAIDZ-2''': Allows for the failure of two disks per RAIDZ-2 group without losing data. A minimum of four disks is required for a RAIDZ-2 group.
*'''RAIDZ-3''': Allows for the failure of three disks per RAIDZ-3 group without losing data. A minimum of five disks is required for a RAIDZ-3 group.
</div><br/><div>To learn more vdev types, please refer to the following article: [[Redundancy in Disks Groups|Redundancy_in_Disks_Groups]]</div><br/>
<span style="font-size:larger">'''2. Add write log'''</span>
<div>This feature allows you to configure the write log function using a chosen redundancy level (either a single drive or a mirror). The write log utilizes a separate intent log (SLOG) device. A fast SSD/NVME should be used for this vdev.</div><br/><div>Key points to consider:
*If multiple log devices are specified, write operations are load-balanced between the devices.
*Log devices can be configured with redundancy by using mirrors to enhance fault tolerance.
*RAIDZ vdev types are not supported for the intent log.
</div><br/><div>This ensures efficient and reliable write operations while leveraging the selected redundancy level.</div><br/>
<span style="font-size:larger">'''3. Add read cache'''</span>
<div>A cache device is used to store frequently accessed storage pool data, providing an additional layer of caching between main memory and disk. These devices cannot be configured as mirrors or RAIDZ groups. A fast SSD/NVME should be used for this vdev.</div><br/><div>Key benefits and considerations:
*Cache devices are particularly useful for '''read-heavy workloads''' where the working dataset size exceeds the capacity of main memory.
*By utilizing cache devices, a larger portion of the working dataset can be served from low-latency storage, improving performance significantly.
*The greatest performance improvements are seen in workloads characterized by '''random reads''' of primarily static content.
</div><br/><div>Adding a read cache helps enhance performance and reduces latency for storage systems with high read demands.</div><br/>
<span style="font-size:larger">'''4. Add special devices group'''</span>
<div>Special devices are used to store specific types of data, such as metadata or small files, on dedicated storage devices separate from the main data pool. A fast SSD/NVME should be used for this vdev.</div><br/><div>Key features and benefits:
*Storing metadata on special devices improves performance for metadata-intensive operations, such as file lookups and directory traversals.
*Small files below a certain size threshold can also be stored on these devices, enhancing read and write speeds for such workloads.
*Special devices are particularly beneficial for environments with a large number of small files or high metadata activity.<div></div>
<div>Using special devices optimizes the overall performance of the ZFS pool by offloading critical metadata and small-file operations to faster storage.</div><br/>
<span style="font-size:larger">'''5. Add deduplication group'''</span>
<div>A deduplication group can be explicitly excluded from a special device group as a dedicated storage group used to hold deduplication tables. This allows the deduplication tables to be stored separately from the special device class.</div><br/><div>Key features and considerations:
*Storing deduplication tables in a dedicated group improves the efficiency of deduplication processes by isolating them from other metadata operations.
*This configuration provides flexibility in optimizing storage layout based on workload requirements.
*Using a deduplication group is particularly beneficial for systems with high deduplication demands, ensuring better performance and management.
</div><br/><div>This setup enhances deduplication performance while maintaining a clear separation of metadata and deduplication operations.</div><br/>
<span style="font-size:larger">'''6. Add spare disks'''</span>
<div>A spare disk is a special pseudo-vdev used to track available spare devices for a zpool.</div><br/><div>Using spare disks enhances the reliability of the storage pool by allowing seamless drive replacement and reducing the risk of data loss.</div><br/>
<span style="font-size:larger">'''7. Configuration'''</span>
<div>During this step, you can configure the Zpool by naming it and enabling additional features if required.</div><br/><div>Key configurations:
*'''Zpool Name''': Assign a unique and descriptive name to the Zpool for easy identification.
*'''Enable AutoTRIM''': If supported by your devices, enable the AutoTRIM feature to automatically reclaim unused space. AutoTRIM helps optimize the performance and lifespan of SSDs by informing them when blocks are no longer in use.
*'''Small blocks policy settings''' if a special device group has been configured in Step. When the small block size is set for the pool all datasets inherit this value by default. It can be changed for a particular dataset in its setting.
</div><br/><div>Proper configuration ensures that the Zpool is tailored to your needs and operates efficiently.</div><br/>
<span style="font-size:larger">'''8. Summary'''</span>
<div>This step provides a summary of the zpool configuration, detailing the arrangement of disk groups and their roles within the pool. Click ‘Add zpool’ to create a zpool.</div>
<br/>'''''<span>Video tutorial related to this article</span>'''''
{{#ev:youtube|aJEZg-F6WQQ}}</div>
[[Category:Help topics]]

Small blocks policy settings

2025-01-15T11:58:03Z

Da-F: Created page with "<div>This feature is available only when the special devices group exists in the pool.</div><br/><div>Devices assigned to the special devices group are designated for storing ..."

<div>This feature is available only when the special devices group exists in the pool.</div><br/><div>Devices assigned to the special devices group are designated for storing specific data, including metadata, indirect blocks of user data, and deduplication tables. Additionally, devices in the special devices group can be configured to handle small file blocks that are not listed above by applying the small blocks policy.</div><div>The size of the small block refers to the size of a single block of data configured on the dataset. Maximum size of such blocks can be set for each dataset under the “Record size” option.</div><div>Deduplication tables can alternatively be placed in a separate group known as the deduplication group.</div><br/><div><span style="color:#ff0000">'''WARNING''': If the size of the small block is greater than or equal to the value of record size on the dataset, all the blocks will be offloaded to the special devices group.</span></div><br/><div>The small block size can be configured for the whole Pool or for each dataset separately. Options to choose range from 4 KiB to 16 MiB.</div><br/><div>Configuring a bigger size for the small block policy can be helpful in case the administrator expects the to have a substantial amount of small files that will require low access times separated from the bigger files. Using this option is recommended only if the administrator understands what kind of data will be stored in configured datasets and the maximum size of offloaded files is exactly known, to avoid accidental data offload and special devices congestion.</div><div>[[Category:Help_topics]]</div><div></div>

Critical system error response policy

2025-01-15T11:39:50Z

Da-F:

<div><span style="color:#ff0000">'''Important!'''</span> <span style="color:#ff0000">Please be aware that these settings are applicable only for a single node configuration or for a cluster configuration with the other node being unavailable.<br/>'''For cluster configuration with both nodes available the policy is set to immediate reboot in all cases'''.</span></div><br/><div>A system reboot may be necessary when a critical error is detected. The administrator may choose to handle different errors in a different manner.</div><br/><div>Possible critical errors are divided into three categories:
*'''ZFS pool I/O suspend''': errors from this group are raised in case an uncorrectable I/O failure is encountered during read/write operation to the Pool. The I/O operation is suspended and the system awaits a reboot.
*'''Kernel oops or bug''': kernel oops is defined as a deviation from the correct behavior of the Linux kernel that produces a certain error log. Such an error is not fatal to the system but may be dangerous to the system’s stability. Kernel oops often precedes a kernel panic, causing the system to immediately shutdown. Kernel bug refers to an internal error in the kernel code. Un-Kh errors put the system integrity at risk. It is highly recommended that a reboot is performed immediately to avoid unexpected failures.
*'''Out-of-memory error''': This error, abbreviated as OOM, refers to the state of the system where no additional memory can be allocated for use by programs or the operating system. It is necessary to free up or add memory to the system to recover the system operation. Once this error occurs the system enters an unresponsive state until the memory issue is solved. It is highly recommended to reboot the system at the first moment possible.
</div><br/><div>For each of the mentioned categories the following behavior patterns can be configured:
*'''Immediate''': system will reboot the machine immediately after the error occurs (the event will not be recorded in the event viewer).
*'''Automatic''': system will restart in 30 seconds from when the errors appear.
*'''Manual''': system will prompt for manual restart.
</div>
[[Category:Help topics]]

Critical IO Errors

2025-01-15T11:38:36Z

Da-F: Da-F moved page Critical IO Errors to Critical system error response policy

#REDIRECT [[Critical system error response policy]]

Critical system error response policy

2025-01-15T11:38:36Z

Da-F: Da-F moved page Critical IO Errors to Critical system error response policy

If a JovianDSS will meet the hardware errors, then a reboot will be needed. 

The reboot procedure may be done by two options :

*'''Immediate''' - System will reboot the machine immediately after a pool has I/O suspended state. No event will be recorded about the reason of it. This option is recommended for cluster configurations because it immediately triggers the failover and therefore it`s the fastest way to restore the access to the data.

*'''automatically''' - System will restart in 30 seconds from when the errors appear.

*'''manually''' - System will prompt for manual restart.

[[Category:Help topics]]

Backup & Recovery replication task

2025-01-15T11:08:06Z

Da-F:

__NOTOC__
== Backup & Recovery: Overview Tabs ==

#'''Tasks''': View the list of all tasks with their current statuses.
#'''Destination Servers''': View all added destination servers. Use the '''Add Server''' button to configure a new server outside of the Backup Task Wizard.
#'''vCenter/vSphere Servers''': View all added vCenter/vSphere servers. Use the '''Add Server''' button to configure a new server outside of the Backup Task Wizard.

For additional support or detailed guidance, refer to the article [[On- and Off-site Data Protection|On-_and_Off-site_Data_Protection]]
<div><br/></div>
== Backup & Recovery: Creating a Replication Task ==

To create a replication task, navigate to '''Backup & Recovery''' and click on the '''Add Replication Task''' button. This launches the Backup Task Wizard, which consists of the following steps:

=== Step 1: Source Configuration ===

#'''Resource Path''': Browse and select the ZVOLs or datasets to be backed up. Confirm your selection by clicking '''Apply'''.
#'''Retention Interval Plan''': Specify how often snapshots should be taken and how long they should be retained.
<div><br/></div>
=== Step 2: Destination Configuration ===

*If the '''Toggle Bar''' is disabled, no destination will be configured. Enable the toggle bar to activate '''Destination 1'''.
*The destination server can be either:
**'''Local Server''': The same machine as the source.
**'''Remote Server''': A different server. To configure a remote server:
**#Select '''Add New Server'''.
**#Provide the following details:
**#*'''IP Address/Domain'''
**#*'''Port''' (default: 40000)
**#*'''Password'''
**#*'''Description''' (optional)
**#After adding the server, select the appropriate '''Resource Path'''.

<span style="color:#ff0000">'''Note''': '''The resource path cannot have iSCSI targets attached (for ZVOLs) or shared datasets.'''</span>

*Specify the '''Retention Interval Plan''' for the destination.
*To configure additional destinations, click '''Add Another Destination'''.

For detailed explanations of these options, refer to the article [[On- and Off-site Data Protection|On-_and_Off-site_Data_Protection]].
<div><br/></div>
=== Step 3: vCenter/vSphere Server Integration ===

*Add a vCenter/vSphere server to enable consistent snapshots.

For detailed instructions, refer to the article [[On- and Off-site Data Protection|On-_and_Off-site_Data_Protection]].
<div><br/></div>
=== Step 4: Task Properties ===

#'''Task Description''': Create a custom description for the task.
#'''Enable MBuffer''': Buffer the data stream on the source and destination to prevent buffer underruns. Configure:
#*'''Buffer Size'''
#*'''Rate Limit'''
#'''Send Compressed Data''': Enable this option to transfer compressed data directly without decompression, which speeds up the process and reduces network bandwidth usage.
<div><br/></div>
=== Step 5: Summary ===

*Review a summary of the configured settings.
*Click '''Add''' to finalize the task.

[[Category:Help topics]]

Backup & Recovery replication task

2025-01-15T11:07:27Z

Da-F:

__NOTOC__

== Backup & Recovery: Overview Tabs ==

#'''Tasks''': View the list of all tasks with their current statuses.
#'''Destination Servers''': View all added destination servers. Use the '''Add Server''' button to configure a new server outside of the Backup Task Wizard.
#'''vCenter/vSphere Servers''': View all added vCenter/vSphere servers. Use the '''Add Server''' button to configure a new server outside of the Backup Task Wizard.

For additional support or detailed guidance, refer to the article [[On- and Off-site Data Protection|On-_and_Off-site_Data_Protection]]
<div><br/></div>
== Backup & Recovery: Creating a Replication Task ==

To create a replication task, navigate to '''Backup & Recovery''' and click on the '''Add Replication Task''' button. This launches the Backup Task Wizard, which consists of the following steps:

=== Step 1: Source Configuration ===

#'''Resource Path''': Browse and select the ZVOLs or datasets to be backed up. Confirm your selection by clicking '''Apply'''.
#'''Retention Interval Plan''': Specify how often snapshots should be taken and how long they should be retained.
<div><br/></div>
=== Step 2: Destination Configuration ===

*If the '''Toggle Bar''' is disabled, no destination will be configured. Enable the toggle bar to activate '''Destination 1'''.
*The destination server can be either:
**'''Local Server''': The same machine as the source.
**'''Remote Server''': A different server. To configure a remote server:
**#Select '''Add New Server'''.
**#Provide the following details:
**#*'''IP Address/Domain'''
**#*'''Port''' (default: 40000)
**#*'''Password'''
**#*'''Description''' (optional)
**#After adding the server, select the appropriate '''Resource Path'''.

<span style="color:#ff0000">'''Note''': '''The resource path cannot have iSCSI targets attached (for ZVOLs) or shared datasets.'''</span>

*Specify the '''Retention Interval Plan''' for the destination.
*To configure additional destinations, click '''Add Another Destination'''.

For detailed explanations of these options, refer to the article [[On- and Off-site Data Protection|On-_and_Off-site_Data_Protection]].
<div><br/></div>
=== Step 3: vCenter/vSphere Server Integration ===

*Add a vCenter/vSphere server to enable consistent snapshots.

For detailed instructions, refer to the article [[On- and Off-site Data Protection|On-_and_Off-site_Data_Protection]].
<div><br/></div>
=== Step 4: Task Properties ===

#'''Task Description''': Create a custom description for the task.
#'''Enable MBuffer''': Buffer the data stream on the source and destination to prevent buffer underruns. Configure:
#*'''Buffer Size'''
#*'''Rate Limit'''
#'''Send Compressed Data''': Enable this option to transfer compressed data directly without decompression, which speeds up the process and reduces network bandwidth usage.
<div><br/></div>
=== Step 5: Summary ===

*Review a summary of the configured settings.
*Click '''Add''' to finalize the task.

[[Category:Help topics]]

Backup & Recovery Esx server

2025-01-15T10:05:52Z

Da-F: Created page with "<div>Snapshot feature can be integrated with VMware ESX/vSphere snapshots. To integrate a new VMware server with click on the “Add server” option.</div><br/> File:V-cent..."

<div>Snapshot feature can be integrated with VMware ESX/vSphere snapshots. To integrate a new VMware server with click on the “Add server” option.</div><br/>
[[File:V-center add server option.png|800px|V-center add server option.png]]
<div>You will be asked for the following information:
*'''IP address''': provide IP address or a hostname associated with your Destination server.
*'''Port''': 443 is set by default. This value should not be changed, unless explicitly asked by the Support Team.
*'''Username''': provide the username for the VMware user you wish to use during integration. It is recommended to use the root user for this purpose.
*'''Password''': to establish the connection, it is required to provide the password to the VMware user account provided in the previous step.
</div><br/>
[[File:Add VMware server form.png|450px|Add VMware server form.png]]
<div><br/>The integrated server will be visible in the table below. The user can browse through the configured datastores and Virtual Machines by going to the Options > Details.</div>
[[File:Details of WMware server.png|800px|Details of WMware server.png]]

[[File:VMware server details.png|450px|VMware server details.png]]
<div><br/>It is also possible to remove the server from integration by clicking the Remove option. <span style="color:#ff0000">'''Remember to remove all Backup tasks related to this server beforehand!'''</span></div>
[[File:Remove WMware server.png|800px|Remove WMware server.png]]

[[Category:Help_topics]]

File:Add VMware server form.png

2025-01-15T10:03:42Z

Da-F:

File:VMware server details.png

2025-01-15T10:03:17Z

Da-F:

File:Details of WMware server.png

2025-01-15T10:03:02Z

Da-F:

File:Remove WMware server.png

2025-01-15T10:02:21Z

Da-F:

File:V-center add server option.png

2025-01-15T10:02:03Z

Da-F:

Backup & Recovery destination server

2025-01-14T13:24:20Z

Da-F:

<div>Remote servers that are added as snapshot targets are called Destination servers. To add one, click the “Add server” button.</div><br/><div>[[File:Add server option.png|none|800px|Add server option.png]]</div><br/><div>You will be asked for the following information:
*'''IP address/domain''': provide IP address or a hostname associated with your Destination server.<br/>'''<u>Note</u>: In case the snapshot target is an HA cluster, it is highly recommended to use Virtual IP configured on a Pool. It allows the connection to be stable even after exporting the pool to the other node'''.
*'''Port''': 40000 is set by default. This value should not be changed, unless explicitly asked by the Support Team.
*'''Password''': to establish the connection, it is required to provide the administrator password to the remote server.
*'''Description''': This field is optional. Provide a short description of your server to identify it in the future.
</div><br/><div>[[File:Add server form.png|none|450px|Add server form.png]]</div><br/><div>Destination servers configured here will be available during the Destination configuration step of the Replication task wizard.</div><div>If you wish to remove the Destination server click the “Remove” button. '''Remember to remove all Backup tasks related to this server beforehand!'''</div><br/><div>[[File:Remove server option.png|none|800px|Remove server option.png]]</div><div>[[Category:Help_topics]]</div>

Backup & Recovery destination server

2025-01-14T13:23:49Z

Da-F: Created page with "<div>Remote servers that are added as snapshot targets are called Destination servers. To add one, click the “Add server” button.</div><br/><div>File:Add server option.p..."

File:Add server form.png

2025-01-14T13:22:47Z

Da-F:

File:Add server option.png

2025-01-14T13:22:23Z

Da-F:

File:Remove server option.png

2025-01-14T13:22:09Z

Da-F:

File:Ad-structure.png

2024-12-19T12:44:52Z

Da-F: Da-F uploaded a new version of "File:Ad-structure.png"