So, I have been thinking of SSDs. I don't have one, I'm just thinking about them. My system is a laptop, so naturally it has to be LUKS LVM for all file systems aside from /boot.
I found
this thread helpful but it does not answer all of my questions, because of the whole layer cake of file system over LVM over LUKS over physical SSD.
Near as I can tell, when blocks are freed up on the file system, the file system has to somehow pass that down to LVM. LVM somehow recognizes that and then passes this down a level to LUKS, which in turn, finally, passes it down to the actual SSD device so that that freed block is marked as unused and can then later be allocated for new files.
I've done a bit of research and here iss what I have been able to figure out, in bottom up order from LUKS up to the file-system. Please correct me when I've made errors from ignorance, as I am sure I have made some. Thank you.
LUKS
When creating a new LUKS device over a SSD, there are no special commands. One would use cryptsetup as one would normally use it; picking cipher and hash, etc.
The only change for an SSD is when using the luksOpen or open options when running the cryptsetup program. Adding the "--allow-discards" option seems to be all that is needed. The man page says, "Allow the use of discard (TRIM) requests for the device. This option is only relevant for open action."
For a fully encrypted system (like mine) this would somehow have to be included in the init ram disk's scripting?
I wonder, can the LUKS block size be set to the same size as the SSD block size? If so, how would one ascertain the SSD's block size? I have read that some SSDs have a block size as high as 128k and that writing in blocks that are smaller than the underlying SSD block size is less than optimal.
LVM
The only option relevant to SSDs is the "--discards" option for the lvcreate program. The man page for lvcreate states: "Specifies how the device-mapper thin pool layer in the kernel should handle discards."
So "--discards passdown" looks like the actual syntax.
Since this would be specified when creating a logical volume, no additional command-line options would need to be added to the init ram disk to mount that volume later on.
If I understand the lvcreate man page correctly, it means that only a thin-provisioned volume can be used with the "--discards passdown" option.
Syntax for creating a thin provisioned LVM is incomprehensible to me at this time. Looks like a pool LVM has to be made first, and all thin volume groups use the pool? the pool itself may or may not be more than one logical volume? Can the pool use the entire volume group or must some free space be left?
Use of thin provisioned volumes has the unfortunate side effect of fragmentation. On an SSD, however, fragmentation does not matter.
The Top Layer
The topmost layer of this layer cake is the actual file system used in each logical volume, whatever it may be; xfs, ext4 or whatever. Some of my reading recommends that one disable journaling, so as to reduce the amount of writes, to then extend the lifetime of the underlying SSD.
ext4
The mount option "discard", either as an "-o" option, or in the fstab, is needed for efficient use of an SSD. So far, seems simple enough.
Journaling will cause extra writes to the disk. ext2 does not use journaling but ext2 does not have the discard option, so is unsuitable for use on an SSD.
As for disabling journaling, from the mke2fs man page:
"mke2fs -t ext3 -O ^has_journal /dev/hdXX" will create a filesystem that does not have a journal and hence will not be supported by the ext3 filesystem code in the Linux kernel."
That's a problem. It would seem that journaling has to be left on!
How much extra writing does ext4 journaling involve? 100% 15%, 2%. Less would be better. If the percentage is low enough, maybe it is OK to just leave journaling on and use ext4?
F2FS
This file system was designed to be used with flash cards, SD cards and SSD drive. The problem is, this file system is new and is possibly not reliable and table enough for regular use.
btrfs
Does it journal?
If one doesn't use snapshots often, since the copy-on-write operations will perform a lot of writes, the day-to-day average amount of writes to an SSD would not be so bad?
Two More Questions
Does the block size of the SSD, LUKS device, LVM physical volume and the file system in all logical volumes need to be the same?
Should part of the disk remain unpartitioned, to allow more blocks to be replace those that become worn (from writes over time).
