Create a Storage Pool
Before implementing the instructions in this section, ensure several EBS volumes have already been created for a AWS SoftNAS® instance, or block storage volumes for Azure, or several VHDs for a VMware vSphere based SoftNAS® VM.
These EBS volumes or VHDs provide the underlying storage for SoftNAS® storage pools. Whenever a volume or VHD is added, it begins as a raw disk which means that the disk has no partitions.
Before disk devices can be assigned to a storage pool, ensure that the disks are partitioned. See Partitioning Disks for more information.
Create a Storage Pool
Click the Storage Pools option under the Storage section in the Storage Administration Panel (on the left) or you can select Step 7 - Create Storage Pool - from the Getting Started Checklist located in the center of the StorageCenter Administrative Interface.
Create a Storage Pool
The Create a New Storage Pool dialog will be displayed.
Enter the name for the storage pool to be created in the Pool Name text entry box.
Some example storage pool naming schemes might include:
Select the redundancy level from the RAID Level drop down list.
Select the disks to be allocated to this storage pool.
In the Choose Pool Options step, check the box in the Forced Creation field to overwrite any older pools on the disks selected.
Adding LUKS Encryption
Choose the required Sync Mode
Sync Mode is an important decision, directly affecting either performance or data integrity. SoftNAS' ZFS based solution provides a great deal of protection to ensure that your data is fully protected, but in a fail-over situation, default settings can potentially result in uncached write bursts not being committed to the target volumes. Sync Mode is one way to prevent this from occurring. Depending on your requirements, choose the required Sync Mode:
Mode | Description |
|---|---|
Standard | This is the default option. Synchronous file system transactions (fsync, O_DSYNC, O_SYNC, etc) are written out (to the intent log) and then secondly all devices written are flushed to ensure the data is stable (not cached by device controllers). For use cases where performance and data integrity are of equal importance, this is the best option. |
Always | For the ultra-cautious, every file system transaction is written and flushed to stable storage by a system call return. This obviously has a big performance penalty. However, if data loss of any kind is unacceptable for your use case, this should be your choice. |
Disabled | Synchronous requests are disabled. File system transactions only commit to stable storage on the next DMU transaction group commit which can be many seconds. This option gives the highest performance. However, it is very dangerous as ZFS is ignoring the synchronous transaction demands of applications such as databases or NFS. Setting sync=disabled on the currently active root or /var file system may result in out-of-spec behavior, application data loss and increased vulnerability to replay attacks. This option does NOT affect ZFS on-disk consistency. Administrators should only use this when these risks are understood. |
Another way to safeguard against data loss without compromising performance is to create a write log, or ZIL. SoftNAS strongly recommends this option for improved performance and data integrity assurance. For in-depth instructions on how to configure a ZIL/write log, see Configuring Read Cache and Write Log. Creating a write log is also covered briefly in a section below.
The new storage pool is created and is ready for use.