This page covers settings that control core behavior of the AIStor process.
You can establish or modify settings by defining:
an environment variable on the host system prior to starting or restarting the AIStor Server.
Refer to your operating system’s documentation for how to define an environment variable.
If you define both an environment variable and the similar configuration setting, AIStor uses the environment variable value.
Some settings have only an environment variable or a configuration setting, but not both.
Each configuration setting controls fundamental AIStor behavior and functionality.
Test configuration changes in a lower environment, such as DEV or QA, before applying to production.
Set a string of parameters to use when starting the AIStor Server.
For Unix-like systems using the recommended MinIO systemd service, use the /etc/default/minio file and create an environment variable MINIO_OPTS for specifying parameters to append to the minio systemd process:
For systems running minio on the command line, MINIO_OPTS is optional.
To use it, declare the environment variable using standard shell semantics, then reference the environment variable when starting up the AIStor Server:
exportMINIO_OPTS=' --console-address=":9001" --ftp="address=:8021" --ftp="passive-port-range=30000-40000" 'Object Store $MINIO_OPTS ...
# The above is equivalent to running the following:# Object Store --console-address=":9001" \# --ftp="address=:8021" \# --ftp="passive-port-range=30000-40000"
There is no configuration setting for this variable, as these settings apply at server startup.
Specifies the full path to the file the Object Store process uses for loading environment variables.
For systemd-managed files, set this value to the path of the environment file (/etc/default/minio) to direct AIStor to reload changes to that file when using mc admin service restart to restart the deployment.
This setting does not have a configuration setting option.
Specifies the number of workers to make available to expire objects configured with ILM rules for expiration.
When not set, AIStor defaults to using up to half of the available processing cores available.
This setting does not have a configuration setting option.
Enables Virtual Host-style requests to the AIStor deployment.
Set the value to the Fully Qualified Domain Name (FQDN) for AIStor to accept incoming virtual host requests.
Omitting this setting directs AIStor to only accept the default path-style requests.
For example, consider a AIStor deployment with an assigned FQDN of minio.example.net.
With path-style lookups, applications can access the bucket using its full path as minio.example.net/mybucket.
With virtual-host lookups, application can access the bucket as a virtual host as mybucket.minio.example.net/.
This setting does not have a configuration setting option.
Removes scanner wait on read/write latency, allowing the scanner to operate at full-speed and IOPS consumption. This setting may result in reduced read and write performance.
fast
Sets a short scanner wait time on read/write latency, allowing the scanner to operate at a higher speed and IOPS consumption. This setting may result in reduced read and write performance.
default
Sets a moderate scanner wait time on read/write latency, allowing the scanner to operate at a balanced speed and IOPS consumption. This setting seeks to maintain read and write performance while allowing ongoing scanner activity.
slow
Sets a medium scanner wait time on read/write latency, where the scanner operates at a reduced speed and IOPS consumption. This setting allows better read and write performance while reducing scanner performance.
May impact scanner-dependent features, such as lifecycle management and replication.
slowest
Sets a large scanner wait time on read/write latency, where the scanner operates at a substantially lower speed and IOPS consumption. This setting prioritizes read and write operations at the potential cost of scanner operations.
May impact scanner-dependent features, such as lifecycle management and replication.
Data Compression
The following section documents settings for enabling data compression for objects.
See Data Compression for tutorials on using these configuration settings.
All of the settings in this section fall under the compression top-level key.
Comma-separated list of the file extensions to compress.
Setting a new list of file extensions replaces the previously configured list.
Defaults to ".txt, .log, .csv, .json, .tar, .xml, .bin".
Specify "*" to direct AIStor to compress all supported file types.
AIStor does not support compressing file types on the Excluded File Types list, even if explicitly specified in this argument.
Comma-separated list of the MIME types to compress.
Setting a new list of types replaces the previously configured list.
Defaults to "text/*, application/json, application/xml, binary/octet-stream".
Comments
This setting does not have an environment variable option. Use the configuration setting instead.
The erasure set size to apply for all drives in a given server pool.
If you set this value, you must do so before you initialize the cluster
The selected stripe size is immutable after the cluster has been initialized and affects any future server pools added to the cluster.
MinIO SUBNET users should log in and open an issue to discuss stripe size settings prior to implementing them in any environment.
This setting does not have a configuration setting option.
Do not change the stripe size setting unless directed to by AIStor engineering.
Changes to stripe size have significant impact to deployment functionality, availability, performance, and behavior.
MinIO’s stripe selection algorithms set appropriate defaults for the majority of workloads.
Changing the stripe size from this default is unusual and generally not necessary or advised.
Defines the default maximum versions to allow per object.
By default, AIStor allows up to the maximum value of an Int64 versions per object, or over 9.2 quintillion.
Arbitrarily high versions per objects may cause performance degradation on some operations, such as LIST.
This is especially true on systems running budget hardware or spinning drives (HDD).
Applications or workloads which produce thousands or more versions per object may require design or architecture review to mitigate potential performance degradations.
Setting a limit of no more than 100 should provide enough versions for most typical use cases.