Talk:SSD

From Gentoo Wiki
Jump to:navigation Jump to:search
Note
Before creating a discussion or leaving a comment, please read about using talk pages. To create a new discussion, click here. Comments on an existing discussion should be signed using ~~~~: 
A comment [[User:Larry|Larry]] 13:52, 13 May 2024 (UTC)
: A reply [[User:Sally|Sally]] 06:06, 26 May 2026 (UTC)
:: Your reply ~~~~
Navigate to first

My rootfs is on LVM on LUKS. Should I trim all layers?

Talk status
This discussion is done as of 14 March 2014.
 # lsblk 
 NAME                    MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
 sda                       8:0    0 465,8G  0 disk  
 ├─sda1                    8:1    0  94,1M  0 part  
 └─sda2                    8:2    0 167,7G  0 part  
   └─root (dm-0)         254:0    0 167,7G  0 crypt 
     ├─vg2-swap (dm-1)   254:1    0     5G  0 lvm   [SWAP]
     ├─vg2-system (dm-2) 254:2    0    50G  0 lvm   /
     └─vg2-home (dm-3)   254:3    0   100G  0 lvm   /mnt/home}}

--Wols (talk) 17:48, 14 March 2014 (UTC)

There is no reason not to, unless you care a lot about people not knowing where you have free space. The data itself is still encrypted, so it's not really an issue. It comes down to personal preference. If it's not about the wiki article, maybe the forums are a better place to discuss this?
Frostschutz (talk) 18:24, 14 March 2014 (UTC)

Confusion about mount options - noatime, nodiratime, relatime - for SSDs

Talk status
This discussion is done as of 2022-02-22.

I am always using a combination of "noatime" and "nodiratime".

  1. ) What would be the best mount option concerning those "atime" options?
  2. ) Is it wise to combine all three: noatime, nodiratime and relatime?

Reference: SSD#Mounting

FILE /etc/fstab
/dev/sda3          /          ext4          defaults,relatime,discard          0 1

Keks24 (talk) 09:13, 24 November 2017 (UTC)

It is probably a question best asked on our forums or Gentoo user mailing lists. Since this is not a proposition to change documentation, we'll mark this discussion as completed. --Maffblaster (talk) 06:26, 23 February 2022 (UTC)

Mistakes in section 'XDG cache'

Talk status
This discussion is done as of 2018-10-28.

1) The first line of the file '/etc/profile.d/xdg_cache_home.sh' ('#!/bin/bash') should be removed. Files in '/etc/profile.d' are sourced - not executed. For that reason, a shebang line doesn't make sense. Even worse: '#!/bin/bash' may misguide a user that he can use bash syntax in this file, which is not true.

2) The section recommends to run 'env-update' after adding or modifying files in '/etc/profile.d'. That's not necessary. env-update is required after modification of a file in "/etc/env.d", but not in "/etc/profile.d".

Mike155 (talk) 01:19, 2 April 2018 (UTC)

The article has been updated following the avobe suggestions.
--Mimosinnet 16:11, 28 October 2018 (UTC)

XDG cache on /run/user/${UID} instead?

Talk status
This discussion is still ongoing.

Perhaps turn 

 if [ ${USER} ]; then
   export XDG_CACHE_HOME="/tmp/${USER}/.cache"
 fi

To 

 export XDG_CACHE_HOME="/run/user/${UID}/.cache"

Since UID is more reliable than username and /run/user/${UID} is reserved for each user.

--Timkenhan (talk) 02:24, 27 May 2022 (UTC)

LVM trim

Talk status
This discussion is still ongoing.

The article states the following in #LVM section:

Alternatively, there is a discard option in lvm.conf which makes LVM discard entire Logical Volume (LV) on lvremove, lvreduce, pvmove and other actions that free Physical Extents (PE) in a VG.
Warning: Enabling it will immediately render the system unable to undo any changes to the LV layout.

I do not understand the warning. I remember creating LVs in one VG (consisting of one PV), and (because I forgot before:) afterwards I changed the default line issue_discards = 0 in /etc/lvm/lvm.conf to issue_discards = 1.

It did not render my system unable to undo any changes to the LV layout: I afterwards added one LV without problems. And I am very sure that removing that logical volume again (undoing its creation) wouldn't have been an issue.

In other words: I don't understand the warning. What does it mean exactly?

Luttztfz (talk) 06:14, 12 July 2024 (UTC)

This should be referring to data recovery. Once you trim a section of the disk, the data is irrecoverable by normal means.
So if you change your lv in a way that discards, you won't get that data back even if you notice right away and don't let anything overwrite the drive regions.
redjard (talk) 13:11, 11 November 2025 (UTC)

rd.luks.options=discard

Talk status
This discussion is still ongoing.

The kernel command line option "rd.luks.allow-discards", currently mentioned on SSD, does not work for me; "rd.luks.options=discard" does. Using sys-kernel/dracut-106-r2, LUKS1, default/linux/amd64/23.0/desktop/systemd profile.

Renergy (talk) forgetting their signature at 10:19, 11 November 2025 (UTC)

See also: https://unix.stackexchange.com/questions/341442/luks-discard-trim-conflicting-kernel-command-line-options
Luttztfz (talk) 12:00, 11 November 2025 (UTC)
It did exist, and doesn't now. https://github.com/dracutdevs/dracut/commit/5ad3803dac7bce984163ff80d022817148f0b84e
I say go ahead update the article, but also is anyone even still using luks1? Might be better to delete the section and maybe reference some better maintained wiki?
redjard (talk) 12:07, 11 November 2025 (UTC)
I was wrong, dracut still has code for handling rd.luks.allow-discards. It also doesn't mention rd.luks.options at all so I'm not sure which component makes use of that. I saw that systemd cryptosetup and crypttab generator files make use of rd.luks.options and systemd has a TODO about missing support for rd.luks.allow-discards so this might be our culprit. https://github.com/systemd/systemd/blob/b131e8d3a478a793956ecd4ab2138e3c4ce5a284/TODO#L1748
If dracut native handling of rd.luks.allow-discards were broken and instead a crypttab were generated with the arguments provided in rd.luks.options, that would explain it I think.
Regardless this seems like a royal pain I question if anyone should have to deal with. Is luks1 still relevant or can we just ignore this and use persistent flags right in the luks header?
redjard (talk) 12:59, 11 November 2025 (UTC)

Cheap SSD is no longer true.

Talk status
This discussion is still ongoing as of 2026-04-03.

The statement "Buying additional, relatively expensive, RAM to use as a tmpfs to save on writes to relatively cheap storage media is not an effective use of resources." is no longer true and should be updated.

Yes and no, because while SSD storage prices went up, RAM prices went up too. But that's not what this sentence is about. It is about the MB per Dollar ratio: 1 GB of RAM is relatively expensive in comparison to 1 GB of SSD storage memory. And this holds true, even when prices (for both, btw) go up. Luttztfz (talk) 15:28, 3 April 2026 (UTC)
Retrieved from "https://wiki.gentoo.org/index.php?title=Talk:SSD&oldid=1433361"