Talk:SSD

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]] 01:37, 27 July 2024 (UTC)
:: Your reply ~~~~

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

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)