I am using OpenStack Cloud and using LVM on RHEL 7 to manage volumes. As per my use case, I should be able to detach and attach these volumes to different instances.
While updating fstab, I have used defaults,nofail for now but I am not sure what exactly I should be using. I am aware of these options:
rw, nofail, noatime, discard, defaults
But I don't how to use them. What should be the ideal configuration for my use case ?
As said by @ilkkachu, if you take a look at the mount(8) manpage, all your doubts should go away. Quoting the manpages:
-w, --rw, --read-write
Mount the filesystem read/write. This is the default. A synonym is -o rw.
Means: Not needed at all, since rw is the default, and it is part of the defaults option
nofail Do not report errors for this device if it does not exist.
Means: If the device is not enable after you boot and mount it using fstab, no errors will be reported. You will need to know if a disk can be ignored if not mounted. Pretty useful on usb drivers, but i see no point on using this on a server...
noatime
Do not update inode access times on this filesystem (e.g., for faster access on the
news spool to speed up news servers).
Means: No read operation is a "pure" read operation on filesystems. Even if you only cat file for example, a little write operation will update the last time the inode of this file was accessed. It's pretty useful on some situations(like caching servers), but it can be dangerous if used on sync technologies like Dropbox. I'm no one to judge here what is best for you, if noatime set or ignored...
discard/nodiscard
Controls whether ext4 should issue discard/TRIM commands to the underlying block device
when blocks are freed.This is useful for SSD devices and sparse/thinly
-provisioned LUNs, but it is off by default until sufficient testing has been done.
Means: TRIM feature from ssds. Take your time to read on this guy, and probe if your ssd support this feature(pretty much all modern ssds suport it). hdparm -I /dev/sdx | grep "TRIM supported" will tell you if trim is supported on your ssd.
As for today, you could achieve better performance and data health by Periodic trimming instead of a continuous trimming on your fstab. There is even a in-kernel device blacklist for continuous trimming since it can cause data corruption due to non-queued operations.
defaults
Use default options: rw, suid, dev, exec, auto, nouser, and async.
tl;dr: on your question, rw can be removed(defaults already imply rw), nofail is up to you, noatime is up to you, the same way discard is just up to your hardware features.
discard can be useful as well for other managed flash storage (MMC/eMMC/SD/CF) devices, /sys/<block-device>/queue/discard_zeroes_data would tell if it's supported, 1 if yes, 0 if no, respectively.
/sys/block/<block-device>/queue/discard_zeroes_data that is.
I came across information that says it is VERY IMPORTANT TO DISABLE DISCARD MOUNT OPTION on SSD's (-o nodiscard) under Linux. Here's the quote and link:
Link:
Quote from page 6:
"Filesystem Recommendations
IMPORTANT: Do not discard blocks in filesystem usage.
Be sure to turn off the discard option when making your Linux filesystem. You want to allow the SSD manage blocks and its activity between the NVM (non-volatile memory) and host with more advanced and consistent approaches in the SSD Controller.
Core Filesystems:
• ext4 – the default extended option is not to discard blocks at filesystem make time, retain this, and do not add the “discard” extended option as some information will tell you to do.
• xfs – with mkfs.xfs, add the –K option so that you do not discard blocks.
If you are going to use a software RAID, it is recommended to use a chunk size of 128k as starting point, depending on the workload you are going to run. You must always test your workload."
As you can see, the manufacturer itself, Intel, makes the point SO STRONGLY that they repeat it FIVE times in the text, FOUR explicitly and one through logic that professionals understand. This is VERY EMPHATIC of the manufacturer. Also, this SSD is no slouch: it is the $1,200 Intel SSD's from a few years ago.
I do not know how the "trim" option relates to any of this; I am passing on the information from the document. The document is dated March 2015, Revision 2.0, and is updated to the Linux Kernel 3.19 (the document lists that on Page 2).
defaults, (or ,defaults) is never needed.
I don't know why the example in man fstab uses it :-(.
The reason to use defaults is if you do not need to provide any options. You need some word to put in the options column, if you want to provide value(s) for the next column(s).
Here's a short summary of each and why you may or may not want them.
rw allows both read and write operations, the alternative is read-only ro. If you need to write data or change metadata (e.g. permissions, access times) then you need rw. Mounting read-only is a safety measure to ensure that data on the volume that is not supposed to be modified should remain unmodified; setting read-only ensures they really are ONLY reading. Suggestion: use read-only unless you need to write. This encourages good practices like restricting writes and side effects to specific locations, and mounting backups and data sources read-only to help maintain their integrity.
nofail and its close relative nobootwait determine how mount and disk check operations like mountall and fsck, respectively, handle failures. As far as I know these are primarily about how disks are handled at boot time. If they are set, then mount operations and the boot process will tolerate missing and failed disks. Suggestion: do NOT use these; you're mounting volumes because you need them. You want your instances to fail fast if their data is inaccessible. If your response is "but that's fine, it should boot anyway** then that's when you want this flag.
noatime disables setting last-accessed times on the filesystem. It's implemented as small writes that occur when a file is accessed. Systems that need (or at least benefit) from this are those that watch for updates to file statuses or want more information about file access patterns. However, these small writes upon access can add up for systems that handle many small files. Disk-based message queues like Apache Kafka in particular really benefit from noatime because it prevents large-volume reads from also forcing a lot of access time updates (aka writes) to occur. Recommendation: skip this unless you have an application that recommends disabling it. In most cases it's negligible in performance and it could interfere with assumptions code in your instances make about file properties.
discard: as another answer reports, SSD manufacturers recommend disabling this. The SSD drivers and firmware are intelligent and can manage deleted files and cleanup by themselves without a mount flag. Recommendation: skip it.
defaults: provides a default list of permissions. Recommendation: skip it. It's better to mount with the flags you need, not the default flags someone else with different priorities came up with.
