Forlæng levetiden på dit SSD-drev med fstrim

Ja, jeg plejer at slå det til som en daglig opgave via systemd.timer.

Ellers så sætter jeg noatime i fstab foran "default" på både root og evt. /home partition, hvis man har sådan en.

Ellers kører jeg /tmp i ram, dvs. med tmpfs. Det forøger hastigheden i OS gevaldigt, og forlænger samtidig også levetiden på SSD'en, da der er færre skrivninger til /tmp. Apps starter også og opererer hurtigere.

Så har jeg min /etc/sysctl.conf sat til, at kun tillade swapping medmindre det er aller højst nødvendigt.

vm.swappiness=1

Og en inode cache pressure på 50.

vm.vfs_cache_pressure=50

Og så har jeg en swapfile i stedet for en swappartition.

For denne konfiguration bør du have RIGELIGT med ram, dvs over 6 GB.

#0
Jeg tror du har

cronjob-fstrim

i synaptic, til formålet.
"Daily cronjob to trim / and /home
This package will setup a daily cronjob to trim your
/ and /home partitions for SSD drives. It is for
those who would rather not tinker with /etc/fstab."

Jeg har ikke, sådan noget moderne isenkram.

#0:En ny måde at trimme din SSD harddisk med. Er der nogen der har erfaring med denne metode

Ja. En gang imellem gør jeg, men jeg kan ikke mærke nogen forskel:

sudo fstrim -a -v

Så ny er metoden nu ikke og der er potentiel risiko for at skade SSD. Før du bruger fstrim, så prøv om du kan finde info fra diskens vendor.

Man kan tjekke om trim er understøttet. Det er det nu på de fleste, men jeg vil ikke råde til, at man slår det til, før man har tjekket, således:

sudo hdparm -I /dev/sda | grep TRIM


Man kan sætte den på daglig systemd.timer ved først, at oprette et catalog (Virker på Debian/Ubuntu) IKKE med sysvinit (PCLinuxOS/MXLinux/Devuan)

sudo mkdir -v /etc/systemd/system/fstrim.timer.d

Dernæst oprette konfigurationsfilen

sudo touch /etc/systemd/system/fstrim.timer.d/override.conf

Åbn konfigurationsfilen

sudo nano /etc/systemd/system/fstrim.timer.d/override.conf

Copy-Paste dette ind

[Timer]
OnCalendar=
OnCalendar=daily

ctrl+x gem filen.

Genstart.

Se, om det er slået til

systemctl cat fstrim.timer

#2: Jeg tror du har

cronjob-fstrim

i synaptic, til formålet.

Ja midsanten, og det var instaleret og kører
cat /etc/cron.daily/fstrim.cron
#!/bin/sh
LOG=/var/log/trim.log
echo "*** $(date -R) ***" >> $LOG
#/sbin/fstrim -v / >> $LOG
#/sbin/fstrim -v /home >> $LOG
/sbin/fstrim -av >> $LOG

Og den kører dagtligt
*** Mon, 10 Feb 2020 07:07:01 +0100 ***
/home: 597,1 GiB (641130323968 byte) trimmet på /dev/nvme0n1p4
/boot/EFI: 5,6 GiB (6013087744 byte) trimmet på /dev/nvme0n1p1
/: 200,5 GiB (215228030976 byte) trimmet på /dev/nvme0n1p2
*** Tue, 11 Feb 2020 15:16:01 +0100 ***
/home: 597,6 GiB (641680703488 byte) trimmet på /dev/nvme0n1p4
/boot/EFI: 5,6 GiB (6013087744 byte) trimmet på /dev/nvme0n1p1
/: 200,9 GiB (215722483712 byte) trimmet på /dev/nvme0n1p2
*** Wed, 12 Feb 2020 08:34:01 +0100 ***
/home: 597,2 GiB (641284870144 byte) trimmet på /dev/nvme0n1p4
/boot/EFI: 5,6 GiB (6013087744 byte) trimmet på /dev/nvme0n1p1
/: 200,9 GiB (215721865216 byte) trimmet på /dev/nvme0n1p2

Så er spørgsmålet, er det nødvendigt at den kører hver dag?



Så er spørgsmålet, er det nødvendigt at den kører hver dag?


Det afhjælper disk performance. Du kan også sætte den til ugeligt, hvis det passer dig bedre, ved, at du modificerer indstillingen.

#3: Så ny er metoden nu ikke og der er potentiel risiko for at skade SSD. Før du bruger fstrim, så prøv om du kan finde info fra diskens vendor.

lshw siger
*-storage
description: Non-Volatile memory controller
product: SSD 660P Series
vendor: Intel Corporation
physical id: 0
bus info: pci@0000:01:00.0
version: 03
width: 64 bits
clock: 33MHz
capabilities: storage pm msi pciexpress msix nvm_express bus_master cap_list
configuration: driver=nvme latency=0
resources: irq:16 memory:a1100000-a1103fff


Jeg fandt dette om disken, men det siger mig ikke noget https://ark.intel.com/content/www/us/en/ark/products/149407/intel-ssd-6…

df -h
Filsystem Størr Brugt Tilb Brug% Monteret på
/dev/root 219G 19G 190G 9% /
/dev 32G 1,1M 32G 1% /dev
none 32G 92M 32G 1% /dev/shm
/dev/nvme0n1p1 5,7G 264K 5,7G 1% /boot/EFI
/dev/nvme0n1p4 709G 114G 595G 17% /home
none 32G 40K 32G 1% /var/run/user/500
/dev/sda1 3,6T 904G 2,6T 26% /media/de4abd56-62d9-46f6-8c98-9c1ba86c63b6

Ignorerer frugalman mig mon?

Jeg prøver, at hjælpe ham.

#10: Ignorerer frugalman mig mon?

Nej men hdparm -I /dev/sda1 | grep TRIM giver ingenting som root
PCLinux kører med SysV så om det betyder noget ved jeg ikke

Hvis du ikke har hdparm installeret, kan det være, at du kan finde den i Synaptic. Hvis du allerede har den installeret, kan det være, at den version du har til PCLOS ikke har de samme muligheder, men andre. Jeg kan ikke lige finde ud af det, men det kan være, at du ikke har den installeret. Kan du bekræfte det?

which hdparm

Ahh, nu kan jeg se fejlen du har lavet. Du har skrevet /dev/sda1 i stedet for/dev/nvme0n1 i kommandoen.

Det var meningen du skulle bruge selve din nvme-disk, ikke en partition, eller anden disk.

#13: Ahh, nu kan jeg se fejlen du har lavet

/dev/sda1 og /dev/nvme0n1 har ikke noget at gøre med om det er SSD diske

/dev/sda er SATA (sd stod oprindeligt for SCSI device) og /dev/nvme er NVME interface

#15: Well, nej, jeg kunne bare se fra hans df, at /dev/sda1 ikke var den device root kørte på, og at det var til media, fordi det er det mountpointet hedder. Så så jeg, at nvme-disken var den device root ligger på.

hdparm -I /dev/nvme0n1 | grep TRIM
HDIO_DRIVE_CMD(identify) failed: Inappropriate ioctl for device

Og jeg har hdparm instaleret

#15 jeg kunne bare se fra hans df, at /dev/sda1

Det er ekstra intern hardisk Som ikke er SSD

: #7 Jeg fandt dette om disken, men det siger mig ikke noget

Jeg vil tro du er bedst tjent med ikke at køre TRIM på disken. Hvis du vil trimme disken, så kan du alternativt vælge at oprette et bash, og nøjes med at køre fstrim ved lejlighed.

Note: Although continuous TRIM is an option (albeit not recommended) for SSDs, NVMe devices should not be issued discards. Discards are disabled by default on typical setups that use ext4 and LVM, but other filesystems might need discards to be disabled explicitly

Intel anbefaler man ikke kører TRIM kontinuerligt. DVS du ikke aktivere fstrim med Cron eller fstab.

Prøv selv at finde mere info på disken: https://www.google.com/search?client=ubuntu&hs=IvY&ei=WE9GXt-IGcedkgWqq…

Noget helt andet er, at du muligvis har nytte af at defragmente din roterende ekstra sda1 med e4defrag, hvis den er Ext4 formateret. Hvis du er tvivl, så lad hellere være.

Som #17 nævner, har du lavet en formateringsfejl i #5

Noatime er anbefalet i stedet for discard. Discard er virkelig en dårlig ting, at bruge. Men alle - selv roterende diske kan faktisk have godt af, at tilføje noatime til fstab.

fstrim er lidt noget andet, end noatime, men de kan bruges sammen. Men som skrevet i artiklen, så bør overtegnede nok overveje, at nøjes med noatime, hvilket burde være mere, end rigeligt.

og frogmaster:

Hvorfor mener du, at e4defrag nødvendigvis er, at foretrække i stedet for fsck -f til roterende diske? fsck med "-f" flag sørger faktisk for, at defragmentere imens den checker for fejl.

#19 Hvorfor mener du, at ext4defrag nødvendigvis er, at foretrække i stedet for fsck -f til roterende diske? fsck med "-f" flag sørger faktisk for, at defragmentere imens den checker for fejl.

Fordi jeg oplever at e4defrag (ikke ext4defrag) defragmentere en roterende Ext4 formateret disk mere effektivt end fsck.

Man bør aldrig bruge fsck uden disken først afmonteres.

e4defrag kræver ikke at disken først afmonteres. Den kan defragmenteres on the fly.

Især på ældre maskiner uden SSD, gør det stor forskel. Man behøver ikke først at starte systemet fra en Live DVD for at defragmentere system disken. Imidlertid er det ikke hvad tråden handler om.

Den handler om hvorvidt det er klogt at benytte cron eller fstab, til kontinuerlig TRIM. Det ved jeg ikke om er klogt, men Archlinux mener at det ikke er anbefalesværdigt.

Det er en del af #0's forespørgsel.

Nu er noatime ikke som sådan TRIM. Det er mere en teknik til, at lade disken se bort fra blokke den ikke behøver at læse fra og skrive til. Ikke som sådan TRiM. Det er mere det discard er, fordi den sætter TRIM igang hver gang du sletter en fil. Det er ikke godt for disken, fordi der er ekstra læsning og skrivning alt for ofte.

Det er det der menes, er jeg sikker på. Noatime er en god ting og er lidt noget andet og ikke progressivt, som fstrim/discard.

Ja. For at få et kvalificeret svar på TRIM af en SSD, ikke mindst NVMe, så skal man nok have svar fra en hardware specialist i SSD. Det kan jeg ikke levere.

Det er fint, at være forsigtig, men lige med hensyn til moderne SSD'er, så er de altså efterhånden så sikre i brug - med den ene og anden beskyttelse bygget ind, så ting som discard, eller TRIM på cron osv. ikke vil gøre det fjerneste.

Hvis vi skruer tiden tilbage til 2010, så er alt det, der står i ArchWiki omkring SSD og TRIM fuldstændigt korrekt. Der er bare den hage, som med så mange andre documentation wikis, at de skal holdes opdaterede, og selvom Arch Wiki vel er kendt for, at være den måske mest omfangsrige WIKI indenfor Linux verdenen, - så skal den også opdateres og holdes tidssvarende. Og lige den del angående TRIM er ikke blevet opdateret i nogle år.

Frugalman, du kan roligt bruge det cron script, det sker der ikke en pind ved. Du kan få performance problemer, hvis du bruger discard i /etc/fstab, men du kan roligt sætte noatime ind i /etc/fstab, men undlad discard for enhver pris.

Men det er ikke sådan, at du smadrer disken, du vil bare få performance problemer. Så undlad discard.

Eller sagt således; hvis du ikke vil risikere noget, så lad være med at trimme disken.

Det er under alle omstændighed kun millisekunder du opnår, muligvis slet ingen, måske tværtimod, og formentlig ingen forskel iht levetid.

Igen, jeg kan ikke mærke forskel på før og efter TRIM på min Linux maskine med SSD. Det kan jeg iøvrigt heller ikke på macOS.

Jeg har en NVMe disk med Windows installeret. På den er Optane aktiv (Intel® Rapid Storage Technology (Intel® RST)) og NTFS, men det er noget helt andet, der ikke har med Linux at gøre.

Jeg kan tilføje den er meget langsommere end Linux maskinen, på trods af at være langt kraftigere og at SSD'en på Linux maskinen er 9 år gammel.

fstrim gør ikke det store, men jeg kan love, at man kan mærke forskel i længen ved brug af noatime (kun Linux). Som sagt er det lidt forskellige
måder, at gøre det på. noatime er på mange måder en aflastning af diskens ressourcer.

Det, og så at bruge tmpfs og deadline scheduler og sætte inode cache pressure til 50, det gør hele forskellen i forhold til performance.
-----------------------------------------------------------------------------------

Til GNOME brugere:

Bruger du GNOME, så findes der en udvidelse, der hedder cpufreq. Den er helt essensiel, da den sørger for, at GNOME kan performe stabilt hurtigt, uden at sløve. Det kræver, at du har en god processor med mindst 4 kerner og mindst i5.

Det den gør, er, at sætte governor til performance og powersaving til performance (hvis du manuelt vælger det) Det kombineret med ovenstående vil skyde performance gevaldigt i vejret og give en god og stabil oplevelse i GNOME med SSD og Intel hardware.

PS. ved brug af cpufreq (GNOME Extension) husk at afinstallere irqbalance. Hav evt. et godt batteri i din bærbar, der ikke er for slidt, hvis du ikke bruger desktop.

cpufreq gnome extension

Ja kik på noatime ...

#1: Og så har jeg en swapfile i stedet for en swappartition.

Det meste af det, du skriver i #1, kan jeg se fornuften i, men swapfile i stedet for swappartition kan vel næppe øge hastigheden eller minimere skrivninger til disk, med mindre du lægger den i Ram.

#27

Det er korrekt. På en SSD er fordelen ved ikke at oprette en Swap partition udelukkende at man ikke spilder plads, især på små SSD, i tilfælde af man ønsker at formindske swapfilen til minimum størrelse, for at udnytte diskpladsen maximalt.

Ja, det er også på grund af, at jeg vil spare diskplads, at jeg har gjort det.

En minimal swapfil kan teoretisk forlænge levetiden af en SSD, eftersom programmer og system, muligvis er i stand til at køre dem i RAM, men det er ikke sikkert de kan det.

Hvis man formindsker swapfilen for meget, så resulterer det i system crash efter en tid. Med en swapfile kan man prøve sig frem. Med swap partition er pladsen brugt.

2 GB er en fornuftig størrelse på en swapfil, hvis man har 16 GB ram, vil jeg tro.

#31: 2 GB er en fornuftig størrelse på en swapfil, hvis man har 16 GB ram, vil jeg tro.
Findes der en tabel over optimal swapfilstørrelse vs. RAM?

Her kan Google nok gøre en forskel, tror jeg. Jeg ved det ikke. Det var mere fordi, at jeg kunne regne ud, at hvis de 16 blev fyldt op, så ville der være rigeligt til, at systemet ikke gik ned med 2 GB, men ikke nok til, at slide på disken.

#23: Frugalman, du kan roligt bruge det cron script, det sker der ikke en pind ved. Du kan få performance problemer, hvis du bruger discard i /etc/fstab, men du kan roligt sætte noatime ind i /etc/fstab, men undlad discard for enhver pris.

Men det er ikke sådan, at du smadrer disken, du vil bare få performance problemer. Så undlad discard.

En strørre diskision om emnet som man kan blive lidt forviret over. Foreløbig nøjes jeg med at fstrim med cron script, så må jeg se om SSD disken kan holde til det.

#27: med mindre du lægger den i Ram.

Fantastisk idé. LOL

#28: Noteret.
#35: Jeg tænkte mest på hastigheden og skrivninger til disk. Jeg kan godt se, at det ikke er nogen god ide.

Hibernation - suspend to disk - kræver vel en swap-partition eller swap-file på størrelse med ens RAM eller ikke alt for meget mindre.
Så 8-16 GB RAM og 2GB swap-file udelukker vel hibernation.

Hibernation er måske ikke så nødvendig på SSD, der er hurtig til opstart.
På den anden side vil hibernation på en SSD måske være mere interessant end sleep - suspend to RAM - netop på grund af hastigheden og muligheden for at spare på batteriet.

Hvad siger I til den problematik?

Ja, du skal nok have mere på den swapfile, hvis du skal hibernate.

I øvrigt har jeg kørt i lange lange tider med Fedora på min nr. 2 Thinkpad med hibernation on lid close slået til.

Det er helt utroligt så meget batteri jeg kan spare. Der kan gå uger i hibernating tilstand, og batteriet er ikke brugt.

#37: Hvad siger I til den problematik?
Jeg er enig, også med #38

Den eneste indvending jeg kender mod hibernation og sleep på en SSD er, at hvis der er opstået en midlertidig fejl, der rettes efter en genstart, så fortsætter fejlen efter wakeup. Personligt bruger jeg aldrig hibernation og sleep.

Jeg er specielt enig i at behovet for hibernation og sleep på en SSD, er begrænset til nemmere fortsættelse af en opgave. Selvfølgelig fordi en SSD er så hurtig til at starte op.

Med en roterende disk, er der potentiel risiko for yderligere fejl, fordi swap filen kan være fragmenteret. På sådan en, kan det give mening at oprette en swap partition, netop for at undgå det, vel og mærke hvis man bruger hibernation e.g..

#39: Den eneste indvending jeg kender mod hibernation og sleep på en SSD er
Der er faktisk en usercase mere, hvor hibernate er skidt: Hvis du kører dualboot på din maskine, og skifter mellem styresystemer. Hvis du så har hibernatet fra den ene, og booter op i den anden, risikerer du at den første har "låst" skriveadgangen til disken.

Det har i hvert fald været et problem tilbage i tiden, og er grunden til at jeg i dag sjældent bruger hibernate -- der ellers fra et brugerperspektiv er helt genialt, fordi man bare kan arbejde videre, hvor man slap.

#40: Hvis du kører dualboot på din maskine, og skifter mellem styresystemer. Hvis du så har hibernatet fra den ene, og booter op i den anden, risikerer du at den første har "låst" skriveadgangen til disken.
Det er rigtigt. Tak for at minde om det. Det er bl.a. derfor jeg idag bruger VM's fremfor dual og trial boot. Måske ikke så meget på grund af hibernate, som jeg alligevel aldrig bruger, men fordi VM's kan håndtere langt flere OS uden risici for fejl i bootloaderne. Det højeste antal VM's har været 12 OS på samme SSD maskine.

På VM's kan man benytte Snapshots, hvis man ønsker en funktion som hibernate på dem (hvad jeg dog heller ikke bruger). Snapshots kan også forårsage fejl.

Der er selvfølgelig ulemper ved VM's, fx grafik acceleration. Den er dog mere effektiv i dag end førhen.

Det mest effektive, og brugssikre, er generelt kun at have et hardware installeret OS pr. maskine. Hvis man ikke gamer eksempelvis, så kan VM's erstatte dualboot, især hvis det primære OS (og emulatoren) er installeret på SSD. VM's kan derimod befinde sig på en ekstra roterende disk, uden stort tab af performance. I så fald bør den defragmenteres.

OK, det er perifert iht #0's forespørgsel, hvor #0 (i #34) vælger at tage chancen med kontinuerlig TRIM.

#42: Men så har vi vel en ny performance suger der kan æde lidt af trim og noatime forbedringerne.
Det er logisk at jo mere en SSD benyttes, derfor også brug af virtuelle maskiner, især hvis de ligger på SSD'en, des mere slides SSD'en.

Ellers ved jeg ikke meget om bedste håndtering af en SSD iht TRIM, noatime, og specielt ikke om det er sundt for disken med kontinuerlig TRIM. Jeg har min tvivl, men ingen viden. Det vil være fedt hvis en specialist i SSD melder sig på banen.

Hvis man har sine virtuelle harddiske liggende på en roterende disk, så er det logisk at det formindsker slidet på SSD'en.

I forlængelse af #41 ved jeg dog at VM's, der ligger på en roterende disk, ikke blot bør defragmenteres fra det primære hardware installerede OS, men derefter også i det virtuelle OS, og den rækkefølge. Grunden er først og fremmest performance.

Befinder virtuelle harddiske sig på en SSD, så glem alt om defragmentering. Emulatoren (VB og VMware) ser alle diske som roterende, selvom systemdisken er SSD. Det kan der teoretisk komme meget potentiel ballade ud af ...

Hvis sidstnævnte er aktuelt, at nogen har en Ubuntu VM liggende på en SSD og nogen skulle finde på at defragmentere den, så har jeg oprettet et bash til formålet, med hjælp her fra sitet, simpelthen for at undgå at skade SSD'en.

Det er vigtigt at nævne, det ikke er en god ide at trimme fra indersiden i en VM under nogen omstændighed. Det skal under alle omstændighed kun gøres fra det hardware installerede OS.

#!/bin/bash
# Define Variables
GREEN='\033[32;1m'
YELLOW='\033[33;1m'
RED='\033[31;1m'
BLUE='\033[34m'
BBLUE='\033[34;1m'
STD='\033[0m'

# Define function (force to use Enter key)
PAUSE_ENTER(){
read -s -p "" fackEnterKey
}

echo "This will defrag the entire ext4 formatted partition without unmounting"
echo "For defrag a specific file or partition, use ..."
echo -e $BBLUE
e4defrag
echo -e $STD

# Checking and installing smartctrl (smartmontools)
echo -e $YELLOW"Checking if Smartmontools and smartctl are installed ..."$STD
if ! [ -x "$(command -v smartctl)" ]; then
echo -e $YELLOW"Smartmontools$RED is needed for checking SSD or HDD rotation rate but is not installed."
echo -e "Press $YELLOW[Enter]$RED to install Smartmontools ..."$STD
PAUSE_ENTER
sudo apt-get update && sudo apt-get install smartmontools
else
echo -e $GREEN"OK$STD Smartmontools is installed."
fi
tput sgr0

# Checking for SSD or rotational
echo
echo -e $YELLOW"Checking if the drive is an SSD or rotational"$STD
rotational=$(sudo smartctl -a /dev/sda | grep 'Rotation Rate')
if [[ "$rotational" =~ "Solid State Device" ]]
then
echo
echo -e $RED"WARNING!$STD ${YELLOW}This is an SSD.$RED Do NOT defrag."$STD
echo -e "You may wish to TRIM the SSD by using the command ${YELLOW}sudo fstrim -a -v${STD} from the terminal"
read -n1 -r -p "Press any key to abort..." key
exit
else
echo
echo -e $GREEN"OK$STD This seems to be an rotational hard drive. It may be safe to defrag"
echo -e "Below another check will be performed that dosen't automaticly abort."
fi
echo
tput sgr0

# Display filesystem
echo -e $YELLOW"Displaying filesystems:"$STD
echo -e $BBLUE
lsblk -f
echo
df
echo -e $STD
echo -e $YELLOW"Save any work and close all programs before continuing"
echo
echo -e "Do you wish to defrag the entire ext4 formatted partition?"$STD
echo -e "You may need to run e4defrag several times depending how much space available"
echo -e "This gonna take a while. Please be patient and do not interrupt"
echo

# Run smartctl for secondly checking if the drive is SSD.
echo "Performing the secondly security check ..."
tput setaf 3
tput bold
sudo smartctl -a /dev/sda | grep 'Rotation Rate'
echo
echo -e $RED"WARNING!$STD If status above shows:$YELLOW Solid State Device$STD, then the automatic SSD check has failed."
echo -e $YELLOW"In that case, PLEASE ABORT NOW to avoid damageing your SSD hard drive"$STD
echo
echo -e "Push$YELLOW Y(es) and [Enter]$STD to defrag or$YELLOW N(o) and [Enter]$STD to abort"

# Starting e4defrag
while true; do
read -p "" yn
case $yn in
[Yy]* ) sudo e4defrag /
echo -e ${GREEN}"Done${STD} ${YELLOW}Do you wanna defrag again?${STD}
Push${YELLOW} Y(es)${STD} or${YELLOW} N(o)${STD} and push${YELLOW} Enter${STD}" ;;
[Nn]* ) exit ;;
* ) echo -e ${YELLOW}"Do you wanna defrag the system?${STD}
Please answer${YELLOW} Y(es)${STD} or${YELLOW} N(o)${STD} and push${YELLOW} Enter${STD}" ;;
esac
done
$SHELL

#1: Ellers så sætter jeg noatime i fstab foran "default" på både root og evt. /home partition
Hvad er noatime??

#1: Og så har jeg en swapfile i stedet for en swappartition
Man skal jo stadigvæk tænke på at 10-20% af ssd'en skal være inaktiv, som så kan bruges til swap-fil/-partition.

#19: Noatime er anbefalet i stedet for discard.
Iøvrigt hvad er discard??

#38: Ja, du skal nok have mere på den swapfile, hvis du skal hibernate.
Var der ik noget med at jeg blev frarådet at køre hibernate i sin tid, nok pga swap-filen/-partitionen mm.

./allan

Man skal jo stadigvæk tænke på at 10-20% af ssd'en skal være inaktiv, som så kan bruges til swap-fil/-partition.

Det var i gamle dage. Det er ikke nødvendigt på moderne SSD.

#45
Det er klart at en disk altid skal have fri plads til at arbejde på. 10 - 20% er minimum alt efter størrelsen på SSD og hvad arbejdet består af.

En swap partition har imidlertid ikke noget med det at gøre. Sådan en er kun spild af plads på en SSD.

Forklaringen er at swap, og andre store filer, som fx VM's, kan være fragmenterede, uden at skabe problemer på en SSD. Derfor også iht hibernation.

Jeg ved ikke om hibernation stadig kan låse skriveadgang til en dualboots andet OS på en SSD, som #40 er inde på, men det vil jeg tro stadig kan ske. I det tilfælde tror jeg det er bedst ikke at bruge enten hibernation eller dualboot.

Det ville være fedt hvis en SSD haj kunne afklare sådan noget. Jeg tør ikke eksperimente på mine SSD. Det ville være for ærgeligt at ødelægge dem blot for det. IHT trådemnet, brug af kontinuelig TRIM.

For interesserede er min ældste SSD 9 år gammel (2011), 120 GB, og har nu 21 bad sectors. Det påvirker endnu ikke Linux Mint 19.3. Jeg har kørt TRIM (fstrim) på den vel omkring 5 gange. Den er overordentlig hurtig.

Selvom den ikke altid har haft Linux installeret, så har den stort set været tændt i samtlige 9 år.

Ja, det er klart, at en SSD skal have minimum 20% fri plads tilbage.

Jeg forstod det som, at 1bot stadig hængte fast i den forældede viden, at man bør reservere ca. 10% uallokeret, uformateret plads i starten af disken, inden man formatterer. Det er nemlig forældet viden. Det behøver de nye diske ikke.

Hej

I det omfang talen kommer til hibernation vil jeg ligesom frogmaster fravælge det, men jeg må tilstå at jeg har gjort brug af sleep-funktionen i win7 på en bærbar, som jeg ik ved om det er hibernation, og iøvrigt er det på en traditionæl spin hhd. Tidligere, før jeg blev bevist om hibernationen, har jeg brugt det ret meget, da jeg havde win7 installeret på en stationær med ssd og ik vidste bedre.

Dualboot bruger jeg ik, da jeg kun installere ét OS på maskinen, og derefter kører virtuelt (vbox) mht de øvrige OS, som jeg måtte have lyst til eller behov for.

Mht swap-filen ved jeg ik lige hvordan man installere på arch, som gør at jeg nok stadig vil gøre brug af swap-partittionen i det omfang at installationen ik selv laver swap-filen. Det kan godt være swap-partitionen er gammeldags, men det virker!

./allan

Hej igen

Jeg er begyndt via terminalen at bruge kommandoen poweroff, hvor jeg har firefox åben samtidig med og så lukker maskinen ned. Fordi jeg bruger denne kombination husker firefox alle mine åbne faner (omkring 100+) ved gendannelsen, når jeg åbner min browser efter opstart af maskinen, som er en anden måde at få browseren til at huske de åbne faner og derved undgå hibernation.

Jeg er godt klar over at det ik er den bedste måde at lukke maskinen ned på, og jeg kan få browseren til at huske de åbne faner, men jeg kan ik lige overskue at bruge history.

DET FALDER MÅSKE LIDT UDEN FOR TRÅDENS EMNE, MEN ER DER EN BEDRE MÅDE AT UNDGÅ HIBERNATION PÅ??

./allan

PS: Jeg håber virkelig på at få et bud/svar, andet end at browseren kan huske mine åbne faner.

Personligt kender jeg primært til hibernate, standby eller den løsning du kender. Jeg er ikke helt sikker på, hvorfor du ikke synes godt om din egen metode (som jeg da egentlig synes lyder ret smart), og derfor er det nok lidt svært at rådgive om en bedre.