• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Total geschriebene Daten auf SSD

BeastXXL

Hacker
Hallo und schöne Feiertage,

ich habe mir vor Kurzem einen neuen PC zusammengebaut und es bei dieser SSD und tmpfs genauso gehalten, wie beim alten PC (auch SSD): ich habe es oS bzw. systemd überlassen. Einzig die etc/tmpfiles.d/tmp.conf habe ich etwas angepasst:
Code:
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

# See tmpfiles.d(5) for details

# Clear tmp directories separately, to make them easier to override
# SUSE policy: we don't clean those directories
d /tmp 1777 root root 7d
d /var/tmp 1777 root root 28d

# Exclude namespace mountpoints created with PrivateTmp=yes
x /tmp/systemd-private-%b-*
X /tmp/systemd-private-%b-*/tmp
x /var/tmp/systemd-private-%b-*
X /var/tmp/systemd-private-%b-*/tmp

# Remove top-level private temporary directories on each boot
R! /tmp/systemd-private-*
R! /var/tmp/systemd-private-*

Nun wollte ich die Einstellungen von tune2fs für / und /home überprüfen:
Code:
beastxxl@linux-5099:~> lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sr0          11:0    1  1024M  0 rom  
nvme0n1     259:0    0 465,8G  0 disk 
├─nvme0n1p1 259:1    0   529M  0 part 
├─nvme0n1p2 259:2    0    99M  0 part /boot/efi
├─nvme0n1p3 259:3    0    16M  0 part 
├─nvme0n1p4 259:4    0  50,2G  0 part 
├─nvme0n1p5 259:5    0   150G  0 part 
├─nvme0n1p6 259:6    0     2G  0 part [SWAP]
├─nvme0n1p7 259:7    0    30G  0 part /
└─nvme0n1p8 259:8    0    50G  0 part /home                                     
beastxxl@linux-5099:~> sudo tune2fs -l /dev/nvme0n1p7
[sudo] Passwort für root: 
tune2fs 1.43.8 (1-Jan-2018)
Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          28a0cea7-1a39-4603-b845-5dfe9c9ab8ba
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              1966080
Block count:              7864320
Reserved block count:     393216
Free blocks:              5751934
Free inodes:              1715889
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Reserved GDT blocks:      1024
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Sun Sep  1 14:27:28 2019
Last mount time:          Tue Dec 24 07:11:59 2019
Last write time:          Tue Dec 24 07:11:59 2019
Mount count:              162
Maximum mount count:      250
Last checked:             Sun Sep  1 14:27:28 2019
Check interval:           15552000 (6 months)
Next check after:         Fri Feb 28 13:27:28 2020
Lifetime writes:          413 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     32
Desired extra isize:      32
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      4f85344c-258e-44a9-94c7-05cd50c30e32
Journal backup:           inode blocks
beastxxl@linux-5099:~> sudo tune2fs -l /dev/nvme0n1p8
tune2fs 1.43.8 (1-Jan-2018)
Filesystem volume name:   <none>
Last mounted on:          /home
Filesystem UUID:          53742a4a-dfb6-4ca2-86c7-1a9ee8dfc09f
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              3276800
Block count:              13107200
Reserved block count:     655360
Free blocks:              12702558
Free inodes:              3273782
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Reserved GDT blocks:      1024
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Sun Sep  1 14:27:29 2019
Last mount time:          Tue Dec 24 07:11:59 2019
Last write time:          Tue Dec 24 07:11:59 2019
Mount count:              162
Maximum mount count:      250
Last checked:             Sun Sep  1 14:27:29 2019
Check interval:           15552000 (6 months)
Next check after:         Fri Feb 28 13:27:29 2020
Lifetime writes:          871 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     32
Desired extra isize:      32
Journal inode:            8
First orphan inode:       1180728
Default directory hash:   half_md4
Directory Hash Seed:      bd0a293f-0e6f-4084-bf69-8db57ecfb905
Journal backup:           inode blocks
Nun bin ich bei der /home-Partition über die 871 GB gestolpert. Daher wollte ich es über systemctl überprüfen:
Code:
beastxxl@linux-5099:~> sudo smartctl -a /dev/nvme0n1
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.12.14-lp151.28.36-default] (SUSE RPM)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Number:                       Samsung SSD 970 EVO Plus 500GB
Serial Number:                      S4EVNF0M451582V
Firmware Version:                   1B2QEXM7
PCI Vendor/Subsystem ID:            0x144d
IEEE OUI Identifier:                0x002538
Total NVM Capacity:                 500.107.862.016 [500 GB]
Unallocated NVM Capacity:           0
Controller ID:                      4
Number of Namespaces:               1
Namespace 1 Size/Capacity:          500.107.862.016 [500 GB]
Namespace 1 Utilization:            121.127.153.664 [121 GB]
Namespace 1 Formatted LBA Size:     512
Namespace 1 IEEE EUI-64:            002538 5491b226b6
Local Time is:                      Tue Dec 24 11:48:39 2019 CET
Firmware Updates (0x16):            3 Slots, no Reset required
Optional Admin Commands (0x0017):   Security Format Frmw_DL Self_Test
Optional NVM Commands (0x005f):     Comp Wr_Unc DS_Mngmt Wr_Zero Sav/Sel_Feat Timestmp
Maximum Data Transfer Size:         512 Pages
Warning  Comp. Temp. Threshold:     85 Celsius
Critical Comp. Temp. Threshold:     85 Celsius

Supported Power States
St Op     Max   Active     Idle   RL RT WL WT  Ent_Lat  Ex_Lat
 0 +     7.80W       -        -    0  0  0  0        0       0
 1 +     6.00W       -        -    1  1  1  1        0       0
 2 +     3.40W       -        -    2  2  2  2        0       0
 3 -   0.0700W       -        -    3  3  3  3      210    1200
 4 -   0.0100W       -        -    4  4  4  4     2000    8000

Supported LBA Sizes (NSID 0x1)
Id Fmt  Data  Metadt  Rel_Perf
 0 +     512       0         0

=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

SMART/Health Information (NVMe Log 0x02, NSID 0x1)
Critical Warning:                   0x00
Temperature:                        36 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    0%
Data Units Read:                    5.381.154 [2,75 TB]
Data Units Written:                 1.137.145 [582 GB]
Host Read Commands:                 36.373.287
Host Write Commands:                13.805.910
Controller Busy Time:               71
Power Cycles:                       198
Power On Hours:                     115
Unsafe Shutdowns:                   23
Media and Data Integrity Errors:    0
Error Information Log Entries:      658
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0
Temperature Sensor 1:               36 Celsius
Temperature Sensor 2:               38 Celsius

Error Information (NVMe Log 0x01, max 64 entries)
No Errors Logged
Wenn ich mich nicht irre, dann hat SMART nur 582 GB geschrieben.

Folgede Fragen:
Wie kann ich zweifelsfrei feststellen, dass /tmp auf tmpfs läuft? Ich dachte df zeigt das, aber stimmt das(?):
Code:
beastxxl@linux-5099:~> df -h
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
devtmpfs         16G    8,0K   16G    1% /dev
tmpfs            16G     58M   16G    1% /dev/shm
tmpfs            16G     18M   16G    1% /run
tmpfs            16G       0   16G    0% /sys/fs/cgroup
/dev/nvme0n1p7   30G    7,5G   21G   27% /
/dev/nvme0n1p8   49G    532M   46G    2% /home
/dev/nvme0n1p2   95M     30M   66M   32% /boot/efi
tmpfs           3,2G     16K  3,2G    1% /run/user/1000

Wie kommt es zu der Angabe von über 800 GB bei der /home-Partition, aber nur ca. 500 GB beim SMART-Kontroller?
Wo ist mein Denkfehler? Ist eine Einstellung falsch, die die Schreibmenge hochtreibt?

Danke für eure Ideen.
 

Sauerland

Ultimate Guru
zu 871 GB
Wahrscheinlich werden nur geschriebene GB gezählt, wenn was gelöscht wird, wird das nicht abgezogen.
 

josef-wien

Ultimate Guru
Wenn Du willst, daß /tmp im Hauptspeicher liegt, mußt Du das in /etc/fstab definieren. Und wenn Du das gemacht hast, brauchst Du keine Eintragungen für /tmp in /etc/tmpfiles.d/tmp.conf.

Die Frage, warum die SSD behauptet, nur 582 GB geschrieben zu haben, mußt Du an Samsung stellen.
 
OP
B

BeastXXL

Hacker
Hallo ihr zwei,

ok, obwohl df einige tmpfs auflistet, muss ich davon ausgehen, dass /tmp nicht vollständig auf tmpfs liegt.
In meiner fstab ist kein Eintrag und systemd bzw. systemctl konnte mir nichts darüber sagen.

Bevor ich die fstab bemühe, will ich es erstmal über systemd versuchen. Ich habe mit
Code:
sudo cp /usr/share/systemd/tmp.mount /etc/systemd/system/tmp.mount
die Datei kopiert.
Als root noch
Code:
[Install]
WantedBy=local-fs.target
eingefügt. Die vollständige tmp.mount-Datei sieht jetzt so aus:
Code:
beastxxl@linux-5099:/etc/systemd/system> systemctl cat /tmp
# /etc/systemd/system/tmp.mount
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=Temporary Directory (/tmp)
Documentation=man:hier(7)
Documentation=https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems
ConditionPathIsSymbolicLink=!/tmp
DefaultDependencies=no
Conflicts=umount.target
Before=local-fs.target umount.target
After=swap.target

[Mount]
What=tmpfs
Where=/tmp
Type=tmpfs
Options=mode=1777,strictatime,nosuid,nodev

[Install]
WantedBy=local-fs.target
Dann noch
Code:
sudo systemctl enable tmp.mount
sudo systemctl start tmp.mount

Nun zeigt mir df folgendes
Code:
beastxxl@linux-5099:/etc/systemd/system> df -h
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
devtmpfs         16G       0   16G    0% /dev
tmpfs            16G    132M   16G    1% /dev/shm
tmpfs            16G    9,7M   16G    1% /run
tmpfs            16G       0   16G    0% /sys/fs/cgroup
/dev/nvme0n1p7   30G    7,5G   21G   27% /
/dev/nvme0n1p8   49G    542M   46G    2% /home
/dev/nvme0n1p2   95M     30M   66M   32% /boot/efi
tmpfs           3,2G     16K  3,2G    1% /run/user/1000
tmpfs            16G       0   16G    0% /tmp

Ich glaube, ganz falsch ist das nicht und ich hoffe (habe ich noch nicht ausprobiert), dass diese Unit nach jedem Systemstart geladen wird.
Aus reiner Neugier: ich habe gelesen, dass die Einrichtung von tmpfs über die fstab gegenüber meiner Methode bevorzugt wird. Warum? Gibt es einen bestimmten Grund?
 

josef-wien

Ultimate Guru
BeastXXL schrieb:
nicht vollständig
Vor Deiner Aktion war der gesamte Inhalt des Verzeichnisses /tmp auf der SSD gespeichert. Dieser Inhalt ist nach wie vor vorhanden, aber Du siehst ihn nicht, da jetzt ein temporäres Dateisystem auf /tmp eingehängt ist und den ursprünglichen Inhalt unsichtbar macht. Mutige hängen die Systempartition ein zweitesmal unter einem anderen Einhängepunkt ein und löschen dort den gesamten Inhalt von /tmp (das leere Verzeichnis /tmp muß aber erhalten bleiben). Weniger Mutige machen das mit einem Live-System.
 
OP
B

BeastXXL

Hacker
Hallo josef,

ich stehe gerade ein wenig auf dem Schlauch. Das, was du beschreibst, ist eigentlich nur dazu gedacht, die SSD von Datenmüll zu befreien, richtig?
Vor die Wahl gestellt, bin ich ein Freund des Live-Systems :D

Du meinst doch das "normale" /tmp-Verzeichnis im root-Ordner, oder? Ich schau mal mit einem Live-System, ob und was ich finde...

Gibt es noch Ideen, was die Diskrepanz der geschriebenen Daten zw. Kontroller und tune2fs erklären könnte? Und ob es gravierende Vor- od. Nachteile gibt zw. den unterschiedlichen Arten ein tmpfs einzurichten (systemd-unit bzw. fstab)?
 
OP
B

BeastXXL

Hacker
Habe es eben ausprobiert und bin verwirrt und unsicher.

/tmp teigt zwar nur leere Ordner an, aber alle mit Zugriffsdaten von heute! Wenn meine Aktion funktionieren würde, dürfte das doch garnicht sein, da ich tmpfs seit gestern eingerichtet hatte.

Funktioniert tmpfs nur richtig über fstab?
 

josef-wien

Ultimate Guru
Was hast Du Dir angeschaut? Das Verzeichnis /tmp des Live-Systems? Das Verzeichnis /einhängepunkt_der_systempartition_von_der_ssd/tmp?



BeastXXL schrieb:
Ja.
BeastXXL schrieb:
Funktioniert tmpfs nur richtig über fstab?
Laut "df -h" vom 24. Dezember 2019, 16:24 Uhr, funktioniert es mit Deiner Lösung (zu der ich nichts sagen kann, denn mein PC ist Sperrgebiet für systemd).
 
OP
B

BeastXXL

Hacker
Ich bin mir recht sicher, dass ich mir den/tmp-Ordner auf der SSD angesehen habe und nicht vom Live-System. Jedenfalls habe ich die gleichen Ordner sowohl beim Live-System als auch unter os15.1 gefunden.

Gerade habe ich folgenden Forumseintrag gefunden:
https://www.linuxquestions.org/ques...ng-output-from-tune2fs-on-sd-card-4175651258/
Möglicherweise hat tune2fs ein Problem mit (S)SD-Speichern oder überinterpretiert etwas.

Mir ist auch aufgefallen, dass meine Aktion evtl. überflüssig war, weil systemd anscheinend das allgemeine /tmp-Verzeichnis nach /run/user/1000 umgeleitet hat:
https://unix.stackexchange.com/questions/162900/what-is-this-folder-run-user-1000(siehe favorisierte Antwort). Dazu passt, dass jedes Mal, wenn ich df ausführe, bei der /run/user/1000-Location kleine Mengen rum liegen (z.B. 16 K), aber bei meinem neu eingerichtetem /tmp-Verzeichnis nichts liegt.

Nagut, meine Aktion zurück zu drehen ist recht einfach. Leider eklärt das weder die Werte von tune2fs noch die Ordner und Zugriffsdaten im /tmp-Ordner auf der SSD.

Evtl. müsste im tmp.conf auch ein "D" statt "d" vor dem Verzeichnissen stehen?
 
OP
B

BeastXXL

Hacker
Vor einigen Tagen ist mir noch eine Diskrepanz aufgefallen, allerdings habe ich vermutlich heute eine Antwort darauf gefunden:
Unter Linux wird mir über smartctl mitgeteilt, dass 741 GB geschrieben wurden:
Ein Auszug von sudo smartctl -x /dev/nvme0
Code:
=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

SMART/Health Information (NVMe Log 0x02, NSID 0xffffffff)
Critical Warning:                   0x00
Temperature:                        36 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    0%
Data Units Read:                    6.324.201 [3,23 TB]
Data Units Written:                 1.448.124 [741 GB]
Host Read Commands:                 50.357.270
Host Write Commands:                24.493.693
Controller Busy Time:               80
Power Cycles:                       218
Power On Hours:                     131
Unsafe Shutdowns:                   23
Media and Data Integrity Errors:    0
Error Information Log Entries:      722
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0
Temperature Sensor 1:               36 Celsius
Temperature Sensor 2:               38 Celsius

Error Information (NVMe Log 0x01, max 64 entries)
No Errors Logged
Alle Tools unter Win sagen mir, dass nur ca. 688 GB geschrieben wurden. Bei den gelesenen Datenmengen ist der Wert unter Linux auch höher.

Auf https://www.smartmontools.org/wiki/FAQ#MyNVMedriveisnotinthesmartctlsmartddatabase findet sich folgender aufschlussreiche Satz:
SCSI/SAS and NVMe drives do not provide ATA/SATA-like SMART Attributes. Therefore the drive database does not contain any entries for these drives. This may change in the future as some drives provide similar info via vendor specific commands (see ticket #870).
Ich vermute daher, dass es hier eine Fehlinterpretation der Daten seitens smartctl gibt.

Leider finde ich keine Hinweise darauf, aber ich vermute eine ähnliche Fehlinterpretation bei den Datenangabe von tune2fs.
 

josef-wien

Ultimate Guru
741 GB = 690 GiB (aber diese Unterscheidung ist noch immer nicht bei allen angekommen).

Ich bezweifle, daß sich ein Dateisystem um die Art der Platte kümmert, aber Du kannst ja die Ext4-Entwickler fragen.
 
Wie kommst Du auf "741GB=690GiB"?
Ich rechne 741.000.000 Byte durch 1024 = 723632,81 MiB und dann nochmals durch 1024 = 706,67 GiB. Oder vereinfacht (741*1000^2)/1024^2. Hab ich da etwa auch einen Denkfehler drin?
 

susejunky

Moderator
Teammitglied
Geier0815 schrieb:
Wie kommst Du auf "741GB=690GiB"?
Ich rechne 741.000.000 Byte durch 1024 = 723632,81 MiB und dann nochmals durch 1024 = 706,67 GiB. Oder vereinfacht (741*1000^2)/1024^2. Hab ich da etwa auch einen Denkfehler drin?
1 GB = 1 000 000 000 Byte (10^9)
741 GB = 741 000 000 000 Byte
741 000 000 000 Byte /1024 /1024 /1024 = 690,110 GiB

Also ich denke josef-wien hat da richtig gerechnet.

Viele Grüße

susejunky
 

whois

Ultimate Guru
???

Geier hat IMHO Recht ein.

1 GB = 1024 MByte = 1048576 KByte = 1073741824 Byte

Oder wo liegt mein Denkfehler, werde ich langsam ALT ??

cu
 

susejunky

Moderator
Teammitglied
whois schrieb:
???

Geier hat IMHO Recht ein.

1 GB = 1024 MByte = 1048576 KByte = 1073741824 Byte

Oder wo liegt mein Denkfehler, werde ich langsam ALT ??

cu
Das mit dem Alter kann ich nicht beantworten, aber Du solltest Dir den Link, den josef-wien in seinem Beitrag genannt hat, durchlesen.

Oder auf die Schnelle:

kB, MB, GB, ... => 10^n mit n=3,6,9, ...
KiB, MiB, GiB ... => 2^n mit n=10,20,30, ...

Viele Grüße

susejunky
 

whois

Ultimate Guru
Hi

OK Dezimal Präfixe....

Man sollte alles lesen.

War mir bis dato so nicht bekannt...

So ist das wenn man über 60 ist ... :eek:ps:

cu
 
Ok, meinen Fehler hab ich jetzt entdeckt: Ich hab nicht auf Byte runter gebrochen sondern hab die KB bzw KiB unterschlagen. Also heißt es (741*1000^3)/1024^3 und dann kommt man tatsächlich auf 690.

Sorry für die Aufregung!
 
OP
B

BeastXXL

Hacker
Aaaachsooooo, ja dann machen die unterschiedlichen Angaben Sinn. Auf die Idee bin ich überhaupt nicht gekommen, weil es bei der vorherigen SSD (keine NVMe) keine Auffälligkeiten gab. Dazu kommt, dass unter Win nichts auf GiB hinweist...

Nagut, aber wie kommt es zu den Unterschieden zw. smartctl und tune2fs?
 
Oben