[gelöst] System durch Festplatte zu langsam?

[buhtz]

...

[NAB]

Vermutlich wird dir gleich ein Moderator erklären, dass du solche langen Texte bei Nopaste:
pastebin/
hochladen sollst und hier dann nur den Link, den du dort bekommst, reinschreiben sollst

Der gesamte abgebildete Bootprozess dauert nur 21 Sekunden, von 00:05:22 bis 00:05:43. Das sieht ziemlich normal aus.

Mit einer Ausnahme: dir schmiert drei mal i915/intel_audio.c ab, jeweils ab dem
" ------------[ cut here ]------------"
bis zum
"---[ end trace "
Danach scheint aber alles normal weiterzulaufen, und da du danach noch 2 Minuten warten musst, bis du eingeloggt bist, hört er ab 00:05:41 wohl auch auf mit Abstürzen.

[Lord_Carlos]

Neue SSD gibt es ab 40 - 50 EUR.
Komisch finde ich das ich die gebraucht auch nicht billiger sehe *gruebel*

Hat vielleicht jemand in deinem Bekanntenkreis eine abzugeben?
So bin ich an zwei 128GB gekommen.

[geier22]

Ich kann mich des Eindrucks nicht erwehren, dass deine Festplatte - aus bisher nicht ersichtlichen Grund - nicht mehr will.
Im recovery mode werden lediglich wenige Units gestartet. Der Zugriff (oder was auch immer das ist) auf dev-sda ist ähnlich lang und addiert sich bei normalem Start (allein bei den Werten > 1min) auf "schlanke" 2,9 Minuten !!
Ich habe mal Siduction Xfce in einer VM installiert: Der Start (bis zur Bedienbarkeit) dauert 28 Sekunden

Code: Alles auswählen

$ systemd-analyze time
Startup finished in 5.588s (kernel) + 10.417s (userspace) = 16.006s
graphical.target reached after 10.375s in userspace

Daten aus dem recovery mode

Code: Alles auswählen

13.377s dev-sda1.device
6.009s systemd-journal-flush.service 
3.289s systemd-udevd.service 
3.253s systemd-tmpfiles-setup.service 
2.693s lvm2-monitor.service 
2.463s systemd-tmpfiles-setup-dev.service 
2.445s systemd-timesyncd.service 
1.823s systemd-modules-load.service 
1.066s keyboard-setup.service

Daten aus normalen Start

Code: Alles auswählen

         17.149s systemd-journal-flush.service
         14.633s dev-sda1.device
         10.316s apt-daily.service
          9.974s NetworkManager-wait-online.service
          8.475s NetworkManager.service
          7.754s ModemManager.service
          6.704s udisks2.service
          6.331s wpa_supplicant.service
          6.067s virtualbox.service
          5.848s networking.service
          5.775s accounts-daemon.service
          5.257s systemd-udevd.service
          4.626s loadcpufreq.service
          4.302s upower.service
          4.004s preload.service
          3.669s lvm2-monitor.service
          3.562s gpm.service
          3.534s dns-clean.service
          3.505s systemd-tmpfiles-setup-dev.service
          3.342s pppd-dns.service
          2.833s systemd-modules-load.service
          2.476s plymouth-quit.service
          2.475s plymouth-quit-wait.service
          2.386s avahi-daemon.service
          2.346s polkit.service
          2.146s proc-sys-fs-binfmt_misc.mount
          2.118s qemu-guest-agent.service
          1.984s keyboard-setup.service
          1.466s lm-sensors.service
          1.438s ssh.service
          1.374s colord.service
          1.329s user@1000.service
          1.153s plymouth-read-write.service
          1.126s systemd-backlight@backlight:acpi_video0.service
          1.064s systemd-logind.service[/quote]

[buhtz]

Ich habe mal Siduction Xfce in einer VM installiert: Der Start (bis zur Bedienbarkeit) dauert 28 Sekunden

Code: Alles auswählen

$ systemd-analyze time
Startup finished in 5.588s (kernel) + 10.417s (userspace) = 16.006s
graphical.target reached after 10.375s in userspace

Wow, vielen herzlichen Dank für den Aufwand!

Nun mache ich mir Gedanken über neue Hardware. Sollte ich dazu vielleicht doch einen neuen Thread öffnen?
Ich besitze hier ein Slim Gehäuse. Da ist ein Steckplatz für ein mSATA SSD Modul. Dazu kann man noch ein 3,5" Gerät (z. B. eine HDD) oder zwei 2,5" Geräte einbauen.

Option 1 ( ~100 € ):
Die ursprüngliche Idee war, zu der aktuellen 3,5" HDD ein mSATA SSD einzubauen. Kosten ~100 € für 256 GB. Da kommt Debian drauf und /home landet, bis auf kleine Ausnahmen die ich per bind-mount regle, weiter auf der HDD.

Option 2 ( ~300 € ):
Nur eine neue 1 TB SSD einbauen. Da sind wir schnell um die ~300,- € (Samsung Evo).

Option 3 ( ~230 € ):
Eine 2,5" SDD mit 250-500 GB für ca. 90 bis 130 € und eine weitere 2,5" HDD für ca. 100,- € noch dazu.

Alle drei Optionen werden Geschwindigkeitsvorteile bringen. Der preisliche Unterschied zwischen den Optionen ist für mich durchaus relevant, aber auch die teuerste Option 2 wäre machbar. Entscheidend für die Auswahl ist eigentlich die Glaskugel-Frage, ob meine aktuelle 3,5" HDD demnächst abraucht. Wenn man die noch als zuverlässig einstufen könnte, würde ich die günstigste Option 1 wählen.

Wenn nicht, stellt sich bei der Wahl zwischen Option 2 & 3 die Frage, was technisch sinnvoller ist. Da gibt es ja einige Mythen bzw. auch veraltete Ansichten bezüglich SSDs. Sollte man heute ein System zu 100% auf eine SSD legen oder ist ein Mischbetrieb (z. B. viele kleine häufig geschriebene Dateien gehören auf die HDD) sinnvoller? Hab dazu nochmal den Thread "SSD: Mython und Realität" aufgemacht.

[Lord_Carlos]

Warum /home auf die HDD?
Viele kleine config und z.B. browser cache liegt in ~/

Ich wuerde /home auf die SSD legen, und dann grosse Daten, also Filme und Bilder auf die HDD.

[buhtz]

Warum /home auf die HDD?
Viele kleine config und z.B. browser cache liegt in ~/

Ich wuerde /home auf die SSD legen, und dann grosse Daten, also Filme und Bilder auf die HDD.

Das wäre inhaltlich auch mein Plan. Diese config und caches in Home wären die Ausnahme, die ich per bind-mount auf die SSD legen würde.
Die "grossen Daten" sind aber auch auf /home.

[NAB]

Also ich sehe keine Hinweise, dass die HDD "nicht mehr will". Aber ich vermute, Grund für die ungewöhnliche Langsamkeit sind viele HDD-Zugriffe. Ich hab nur keine Ahnung, was das sein könnte. Ich hab schon geguckt, ob XFCE inzwischen einen Datei-Indexer haben könnte, so wie KDE, aber ich find da nix.

buhtz, schau dir noch mal die Ausgabe von
journalctl -b
an. Es geht weniger darum, was da drin steht, sondern ob da was jede Sekunde reinschreibt. Und schau noch mal unter /var/log/ nach, ob da eine Datei auffällig alle paar Sekunden wächst.

Ebenfalls interessant ist ~/.xsession-errors
Wie groß ist die? Wächst die dauernd?

[geier22]

Also ich sehe keine Hinweise, dass die HDD "nicht mehr will". Aber ich vermute, Grund für die ungewöhnliche Langsamkeit sind viele HDD-Zugriffe. Ich hab nur keine Ahnung, was das sein könnte. Ich hab schon geguckt, ob XFCE inzwischen einen Datei-Indexer haben könnte, so wie KDE, aber ich find da nix.

Aber im recovery mode ist sie doch auch nicht wesentlich schneller. Da ist Xfce noch gar nicht gestartet. Das ist ja das seltsame

[buhtz]

journalctl -b

Da werde ich immer noch nicht warm mit. Wie bekomme ich journalctl dazu mir automatisch neue Einträge anzuzeigen - so wie früher mit tail -f log.file ?

Ebenfalls interessant ist ~/.xsession-errors
Wie groß ist die? Wächst die dauernd?

Die ist mal eben 82MB groß. Da stehen aber keine Zeitstempel drin - was ein log file IMO wertlos macht.

[DeletedUserReAsG]

Wie bekomme ich journalctl dazu mir automatisch neue Einträge anzuzeigen - so wie früher mit tail -f log.file?

Code: Alles auswählen

journalctl [OPTIONS...] [MATCHES...]

Query the journal.

Options:
[…]
  -f --follow                Follow the journal
[…]

… geht immer noch wie früher™, mit ›Befehl --help‹ und auch ›man Befehl‹.

[buhtz]

… geht immer noch wie früher™, mit ›Befehl --help‹ und auch ›man Befehl‹.

Unter follow konnte ich mir aber nix vorstellen. Es fehlt mir einfach häufig auch der korrekte Suchbegriff im Kopf.

Hatte gerade spontan die IDee ein zweites Desktop-Environment zu installieren und den Start mal zu messen. Hatte Xfce schon immer im Verdacht. X hat aber gerade diverse Bugs offen, so dass ich das in Debian unstable nicht tun kann.

[DeletedUserReAsG]

Naja … heißt in der --help-Ausgabe von tail genauso.

[buhtz]

journalctl -b
an. Es geht weniger darum, was da drin steht, sondern ob da was jede Sekunde reinschreibt. Und schau noch mal unter /var/log/ nach, ob da eine Datei auffällig alle paar Sekunden wächst.

Wärend dem booten ist das schwer zu überwachen.

Konnte mich mit einer zweiten Maschine ab X-start per SSH einloggen und das journal-log verfolgen. Bin da kein Fachmann, aber es sieht nicht auffällig aus. Keine besonders häufiges Schreiben oder so.

[geier22]

Hmm - ich bin der Meinung, wenn das Problem mit deiner dev-sda1 nicht gelöst wird, brauchst du auch nach anderem nicht zu sehen.
Und das lässt sich am übersichtlichsten im recovery modus machen.
wenn du da als root eingeloggt bist,

Code: Alles auswählen

journalctl -b  > irgendeinen Datei in deinem Home.txt

Du kannst die ganze Datei auch hier einstellen aber bitte nach NoPaste

Daten aus dem recovery mode, die du ja schon eingestellt hattest:

Code: Alles auswählen

 
         13.377s dev-sda1.device
          6.009s systemd-journal-flush.service
          3.289s systemd-udevd.service
          3.253s systemd-tmpfiles-setup.service
          2.693s lvm2-monitor.service
          2.463s systemd-tmpfiles-setup-dev.service
          2.445s systemd-timesyncd.service
          1.823s systemd-modules-load.service
          1.066s keyboard-setup.service
           974ms systemd-journald.service
           844ms systemd-backlight@backlight:acpi_video0.service
           681ms sys-kernel-debug.mount
           677ms systemd-remount-fs.service
           622ms systemd-random-seed.service
           619ms dev-mqueue.mount
           614ms dev-hugepages.mount
           315ms systemd-udev-trigger.service
           229ms systemd-update-utmp.service
           186ms plymouth-start.service
           175ms plymouth-read-write.service
           171ms blk-availability.service
            97ms systemd-sysctl.service
            88ms kmod-static-nodes.service
            87ms dev-disk-by\x2duuid-a0fdc21c\x2de2e7\x2d4b92\x2d93bc\x2d5ebb5a2f32e6.swap
             5ms systemd-update-utmp-runlevel.service

Das Journal kannst du dir dann ganz in Ruhe anschauen und nach Zeitsprüngen, Fehlermeldungen und Warnungen suchen.

Die ist mal eben 82MB groß.

Das weißt darauf hin, dass du dich bisher nicht allzu viel um dein System gekümmert hast, oder ein wild gewordenes Programm die Datei voll-schreibt.
Abhilfe: löschen, auch die xsession-errors.old ---> wird beim Neustart wieder angelegt und ist dann aussagefähiger.
oder im "live" Modus:

Code: Alles auswählen

$ >~/.xsession-errors

[MSfree]

Ich würde erstmal die quiet Option aus /boot/grub/grub.cfg entfernen (vorher /boot/grub/grub.cfg sichern). Dann sieht man eigentlich schon beim Booten, welche Schritte lange dauern.

Mich würde auch (nochmal) die svg-Datei von system-analyse interessieren, aber als svg und nicht als Bild. Das ist nämlich eine ASCII-Datei, die man z.B. nach nopaste hochladen kann. Dann kann man darin auch zoomen und es wird nicht so unscharf wie in einem Screenshot.

[buhtz]

Ich würde erstmal die quiet Option aus /boot/grub/grub.cfg entfernen

Da seh ich kein quit. Hab ich wahrscheinlich früher schon entfernt. Ich sehe beim booten jedenfalls die Logs auf dem Schirm. Schlau werd ich daraus nicht.

journalctl -b im recovery mode

journalctl -b nach normlen Booten

.xsession-errors nach dem ich diese vorher im recovery mode gelöscht und dann einen Reboot gemacht hatte.

systemd analyze plot

Was mir im Journal so auffällt...

• Da steht immer was von nem RAID. Hab hier aber keins laufen. Warum muss das da sein? Scheinbar wird mdadm per default installiert?
• Das Abstürzen dieses Treibers (Audio?) i915_audio_component_bind_ops
• Ab Zeitstempel Feb 25 13:49:57 kommen Zeitsprünge/Pausen rein.

[geier22]

Hab mir mal die Mühe gemacht, Mein log (VM mit Siduction Xfce) mit deinem (normales Booten)oberflächlich zu vergleichen,
und ein paar Punkte als Vergleich raus gezogen:

Code: Alles auswählen

13:49:21 TONNE kernel: microcode: microcode updated early to revision 0x22, date = 2017-01-27
13:49:21 TONNE kernel: Linux version 4.15.3-towo.1-siduction-amd64 (towo@siduction.org) (gcc version 7.3.0 (Debian 7.3.0-3)) #1 SMP PREEMPT siduction 4.15-7 (2018-02-12)
13:49:21 TONNE kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-4.15.3-towo.1-siduction-amd64 root=UUID=6419425e-7001-4b2c-9c4b-9ef782249916 ro systemd.show_status=1
13:49:22 TONNE systemd-journald[325]: Time spent on flushing to /var is 1.892238s for 693 entries.
13:49:22 TONNE systemd-journald[325]: System journal (/var/log/journal/9f1a96d12f774916baa8d0d3c94bfa06) is 88.0M, max 4.0G, 3.9G free

6 Sec. Sprung die Schritte, die System macht (13:49:22 - 13:49:28) werden seltsamer Weise erst im Anschluss aufgeführt

13:49:28 TONNE kernel: lp: driver loaded but no devices found
13:49:29 TONNE systemd[1]: Started udev Kernel Device Manager
13:49:34 TONNE systemd[1]: Reached target System Initialization
13:49:34 TONNE systemd[1]: Started D-Bus System Message Bus.
13:49:43 TONNE NetworkManager[625]: <info>  [1519562983.9631] NetworkManager (version 1.10.4) is starting... (for the first time)
13:50:00 TONNE sddm[813]: Authenticated successfully
13:49:51 TONNE sddm[813]: Starting...
13:49:53 TONNE systemd[1]: Startup finished in 9.094s (kernel) + 36.602s (userspace) = 45.697s.
13:49:53 TONNE colord[805]: failed to get session [pid 635]: Keine Daten verfügbar
13:49:57 TONNE systemd[1]: Reloading OpenBSD Secure Shell server.
13:49:57 TONNE nm-dispatcher[790]: req:3 'connectivity-change': start running ordered scripts...
13:50:02 TONNE systemd[1078]: Startup finished in 862ms.
13:50:02 TONNE systemd[1]: Started User Manager for UID 1000.

Code: Alles auswählen

14:37:47 sidxfce kernel: Linux version 4.15.5-towo.1-siduction-amd64 (towo@siduction.org) (gcc version 7.3.0 (Debian 7.3.0-5)) #1 SMP PREEMPT siduction 4.15-10 (2018-02-23)
14:37:47 sidxfce systemd-journald[291]: Time spent on flushing to /var is 250.766ms for 450 entries.
14:37:47 sidxfce systemd-journald[291]: System journal (/var/log/journal/470c513d6ab441fbbddd5e13da1ea4bc) is 88.0M, max 1.5G, 1.4G free.
14:37:47 sidxfce systemd[1]: Started Load/Save Random Seed.
14:37:47 sidxfce systemd[1]: Reached target System Time Synchronized
14:37:49 sidxfce systemd[1]: Started udev Kernel Device Manager.
14:37:52 sidxfce systemd[1]: Reached target System Initialization
14:37:52 sidxfce systemd[1]: Started D-Bus System Message Bus.
14:37:54 sidxfce NetworkManager[564]: <info>  [1519565874.8033] NetworkManager (version 1.10.4) is starting... (for the first time)
14:37:56 sidxfce sddm[672]: Starting...
14:37:59 sidxfce systemd[1]: Startup finished in 4.169s (kernel) + 13.657s (userspace) = 17.827s
14:38:01 sidxfce sddm[672]: Authenticated successfully
14:38:01 sidxfce systemd[1370]: Startup finished in 236ms.
14:38:01 sidxfce systemd[1]: Started User Manager for UID 1000

Time spent on flushing to /var is 1.892238s for 693 entries.
gegen
Time spent on flushing to /var is 250.766ms for 450 entries.

Sagt an sich schon alles.

Jeder intensivere Zugriff auf deine Platte nach dem Start von "User Manager for UID 1000" potenziert das Ungemach. Ob da nun noch zusätzlich Fehler
in irgendwelchen Programmen oder in der ~/.xsession-errors auftauchen wird das Grundproblem nicht beheben, höchstens mildern.

[NAB]

Hmm - ich bin der Meinung, wenn das Problem mit deiner dev-sda1 nicht gelöst wird, brauchst du auch nach anderem nicht zu sehen.
Und das lässt sich am übersichtlichsten im recovery modus machen.

Welches dev-sda1 Problem siehst du denn da? Im Recovery-Modus braucht das System 11 Sekunden (13:43:37 bis 13:43:48), bis das eigentliche Booten abgeschlossen ist. Ohne Recovery-Modus sind es 13 Sekunden (13:49:21 bis ca. 13:49:34). Gut, das ist kein Rennpferd, aber weit von den geschilderten Minuten Verzögerung entfernt.

Um 13:50:03 meldet sddm "Session started" - 42 Sekunden nach Systemstart. Danach macht er 7 Sekunden Pause - was macht er da?

Und selbst wenn die Kiste drei Minuten bis zum Desktop braucht ... da werden ja auch ne ganze Menge Dienste gestartet ... erklärt das noch nicht, warum Firefox danach 22 Sekunden zum Starten braucht.

Ich seh da aber immer noch nichts, was permanent auf die Platte zugreifen könnte. Ich seh nur komische Sprünge von zwei bis vier Sekunden, während der Rechner eigentlich noch eifrigst mit dem Starten der Dienste beschäftigt sein sollte.

Time spent on flushing to /var is 1.892238s for 693 entries.
gegen
Time spent on flushing to /var is 250.766ms for 450 entries.

Sagt an sich schon alles.

Sehr schöner Vergleich, aber ... woran liegt's? So ein richtig gutes Gewissen hätte ich nicht, wenn ich buhtz sage "Kauf dir ne neue Platte und alles wird gut".

buhtz, festplattenbezogen sehe ich das hier:

Code: Alles auswählen

smartd[632]: Test of /usr/share/smartmontools/smartd-runner to user produced unexpected output (183 bytes) to STDOUT/STDERR:

smartd will irgendwas "Komisches" melden, kann dir aber keine Mail schicken:

Code: Alles auswählen

smartd[632]: Your system does not have /usr/bin/mail.  Install the mailx or mailutils package

Du könntest "smartmontools" mal testweise deinstallieren ... einige Platten mögen das nicht, wenn sie dauernd per SMART belästigt werden (das sollte aber eigentlich Meldungen im dmesg geben)

Und bei 13:50:29 stürzt dir wieder i915/intel_audio.c:757 ab. (Das erste mal bei 13:49:34 - er tut's also nicht nur einmal). Ob das was mit deinen Problemen zu tun hat, weiß ich nicht, aber so richtig gesund sieht das nicht aus.

[buhtz]

Ich danke euch wirklich sehr, dass ihr euch da so reinhängt!

Time spent on flushing to /var is 1.892238s for 693 entries.
gegen
Time spent on flushing to /var is 250.766ms for 450 entries.

Sagt an sich schon alles.

Jeder intensivere Zugriff auf deine Platte nach dem Start von "User Manager for UID 1000" potenziert das Ungemach.

Was "sagt" das? Sorry, kann nicht folgen. Was bedeutet in diesem Kontext "flushing". Warum dauert es "lange"?

So ein richtig gutes Gewissen hätte ich nicht, wenn ich buhtz sage "Kauf dir ne neue Platte und alles wird gut".

Danke für den Hinweis - genau in dem Punkt hardere ich eben.

festplattenbezogen sehe ich das hier:

Code: Alles auswählen

smartd[632]: Test of /usr/share/smartmontools/smartd-runner to user produced unexpected output (183 bytes) to STDOUT/STDERR:

smartd will irgendwas "Komisches" melden, kann dir aber keine Mail schicken:

Code: Alles auswählen

smartd[632]: Your system does not have /usr/bin/mail.  Install the mailx or mailutils package

Du könntest "smartmontools" mal testweise deinstallieren ...

Wäre es nicht sinnvoller hinzuhören, was smartmontools mir hier sagen möchte? Ja, das mit dem mails verschicken auf dem lokalen Rechner, hatte ich früher mal probiert und dann aber nicht zu ende (und vielleicht "kaputt") konfiguriert. Hab jetzt mal mailutils installiert. Mein user und auch root bekommen aber keine Mail von smartmontools.

Und bei 13:50:29 stürzt dir wieder i915/intel_audio.c:757 ab.

Unter Windows würde ich den Treiber im Gerätemanager deinstallieren und beim nächsten Reboot hoffen, das W automatisch den passenden Treiber neu und korrekt installiert.
Was erwartet Debian in so einem Fall vom User? Neben: Der Sound funkioniert eigentlich.

[RobertS]

…Mein user und auch root bekommen aber keine Mail von smartmontools. …

Schau mal in das Verzeichnis /var/mail/

[NAB]

Was bedeutet in diesem Kontext "flushing".

"Auf die Festplatte schreiben"

Warum dauert es "lange"?

Genau das ist die Frage!

Wäre es nicht sinnvoller hinzuhören, was smartmontools mir hier sagen möchte?

Erfahrungsgemäß - nein. Wenn die Platte wirklich SMART-Fehler verzeichnet hätte, müssten die unter smartctl -a auftauchen.

Ach, sag mal ... hast du die Platte eigentlich gebraucht gekauft? Zwischen 7622 und 7928 Betriebsstunden hat jemand ziemlich viele "SMART Short offline"-Tests gemacht. Du bist jetzt bei 13264 Betriebsstunden. Vielleicht hat da schon jemand vor dir an dem Ding verzweifelt?

Was erwartet Debian in so einem Fall vom User?

Dass du einen Debian Kernel benutzt. Und so ein bisschen weißt, was du tust, wenn du unbedingt Sid benutzen willst.

[buhtz]

Schau mal in das Verzeichnis /var/mail/

Keine Mails.

Code: Alles auswählen

$ mail
Postfach /var/mail/user kann nicht geöffnet werden: Keine Berechtigung
Keine Nachrichten für user
user@TONNE:~$ sudo mail
Keine Nachrichten für root
user@TONNE:~$ ll /var/mail
insgesamt 0
-rw------- 1 root mail 0 Feb 25 18:06 root
user@TONNE:~$ ll /var/mail/root
-rw------- 1 root mail 0 Feb 25 18:06 /var/mail/root

Ach, sag mal ... hast du die Platte eigentlich gebraucht gekauft? Zwischen 7622 und 7928 Betriebsstunden hat jemand ziemlich viele "SMART Short offline"-Tests gemacht. Du bist jetzt bei 13264 Betriebsstunden. Vielleicht hat da schon jemand vor dir an dem Ding verzweifelt?

Die Platte war neu. Habe dazu aber eine Theroie. Die Platte hatte bisher drei "Lebensphasen".

• Zuerst war sie in einem QNAP NAS auf dem auch das OS von QNAP installiert war. D. h. keine Kontrolle durch mich.
• Dann hatte ich Debian auf dem Gerät.
• Und jetzt läuft die Platte alleine in meinem Desktop.

In der zweiten Phase habe ich vermutlich mit smartmontools experimentiert und dabei wahrscheinlich eine Art automatischen und regelmäßigen Short Test (über den smartd?) aktiviert. Das würde auch in etwa zu den Life Time Hours passen.

[BenutzerGa4gooPh]

RobertS hat geschrieben: So 25. Feb 2018, 18:42
Schau mal in das Verzeichnis /var/mail/
Keine Mails.
$ mail
Postfach /var/mail/user kann nicht geöffnet werden: Keine Berechtigung

Nimm einfach mal den Dateimanager (Thunar) und dann den Editor (Doppelklick).

Dann schaue in den XFCE-Einstellungen nach unnötigen Diensten beim Start und deaktiviere diese.
Bei mir sind's etliche weniger als bei dir.
Sitzung und Startverhalten -> Automatisch gestartete Anwendungen sowie -> Fortgeschritten

Der Aufbau deiner Netzwerkverbindung dauert ebenfalls ungewöhnlich lange. Mal prüfen, evtl. anderer Thread.

Und dann:

Code: Alles auswählen

su -
update-initramfs -k all -u
update-grub

Hat sich bei mir (sda8 = /home) danach verbessert:

Code: Alles auswählen

5.702s dev-sda8.device

Reboot und vergleiche mit deinen Ausgangswerten:

Code: Alles auswählen

systemd-analyze blame

Zum Vergleich, was bei mir > 1 s dauert:

Code: Alles auswählen

systemd-analyze blame
          7.544s NetworkManager-wait-online.service
          7.309s keyboard-setup.service
          5.702s dev-sda8.device
          2.996s ModemManager.service
          1.952s NetworkManager.service
          1.666s ssh.service
          1.429s systemd-logind.service
          1.407s lm-sensors.service
          1.388s rsyslog.service
          1.362s systemd-fsck@dev-disk-by\x2duuid-6a8fe936\x2dd6f5\x2d45ad\x2d917c\x2deeab0cd3e2fc.service
          1.352s rtkit-daemon.service
          1.009s lightdm.service
          <snip>

HDD mit ähnlichen hdparm-Werten wie deine:

Code: Alles auswählen

hdparm -tT /dev/sda8
/dev/sda8:
 Timing cached reads:   22790 MB in  1.99 seconds = 11426.35 MB/sec
 Timing buffered disk reads: 298 MB in  3.00 seconds =  99.31 MB/sec

systemd-analyze time
Startup finished in 3.701s (kernel) + 23.083s (userspace) = 26.784s

"Hänger" bzw. Bootmeldungen sichtbar während Bootvorgang (hinter # Defaults):

Code: Alles auswählen

nano /etc/default/grub 
#GRUB_CMDLINE_LINUX_DEFAULT="quiet"
GRUB_CMDLINE_LINUX_DEFAULT=""
update-grub

[geier22]

hmm ---- man solls nicht glauben, was es da für Differenzen gibt. Mal ein Vergleich:

Code: Alles auswählen

309   ms dev-sdc1.device   ----> SDD (SATA Samsung SSD 850)
1520  ms dev-sda1.device ------> Faktor   4,91909385113 Hans VM in Vrtualbox (von Seagate ST2000DX002-2DV1)
5702  ms dev-sda8.device ------> Faktor  18,4530744337 Jana
13035 ms dev-sda1.device ------> Fakotor 42,1844660194  Buhts

die Seagate ist meine neuste Errungenschaft gestern erst eingebaut.

Aber ich bin trotzdem der Meinung dass das alles nichts nützen wird. Buhts Platte hat aus irgend einem Grund, der nicht bekannt ist ein echtes "Schreib- und Leseproblem". Eventuell kann man das partiell verbessern, aber die Verzögerungen bei jedem Plattenzugriff setzen sich durch alle Aktivitäten der Platte fort.