X301: Bootzeit von SSD

jal2

Active member
Registriert
7 Sep. 2010
Beiträge
3.708
Hallo,

ich betreibe eine Crucial M500 mSATA in einem X301 (SU9400 @ 1,4GHz) und finde, dass es etwas langsam bootet.
Auszuege aus der Ausgabe von dmesg:

Code:
[    0.404705] Trying to unpack rootfs image as initramfs...
[    1.419090] Freeing initrd memory: 18708K (ffff880035b66000 - ffff880036dab000)
...
[    2.055892] PTP clock support registered
[    2.064925] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
[    2.064929] e1000e: Copyright(c) 1999 - 2013 Intel Corporation.
[    2.065183] e1000e 0000:00:19.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
[    2.065219] e1000e 0000:00:19.0: irq 42 for MSI/MSI-X
[    2.272304] e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) 00:21:86:a3:d6:07
...
[    3.408283] input: AlpsPS/2 ALPS DualPoint TouchPad as /devices/platform/i8042/serio1/input/input5
[    7.667406] EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: (null)
[    7.775525] random: init urandom read with 62 bits of entropy available
[    7.821507] init: plymouth-upstart-bridge main process (163) terminated with 
status 1
[    7.821533] init: plymouth-upstart-bridge main process ended, respawning
[    7.839526] init: plymouth-upstart-bridge main process (173) terminated with 
status 1
[    7.839553] init: plymouth-upstart-bridge main process ended, respawning
[    7.853996] init: plymouth-upstart-bridge main process (176) terminated with 
status 1
[    7.854022] init: plymouth-upstart-bridge main process ended, respawning
[    8.052786] random: nonblocking pool is initialized
[    9.001273] Adding 13938684k swap on /dev/sda5.  Priority:-1 extents:1 across:13938684k SSFS
[    9.015254] EXT4-fs (sda3): re-mounted. Opts: errors=remount-ro
[   10.031411] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
...
[   12.768142] usbcore: registered new interface driver cdc_ether
[   13.155011] type=1400 audit(1409504445.679:11): apparmor="STATUS" operation="
profile_replace" profile="unconfined" name="/sbin/dhclient" pid=896 comm="apparm
or_parser"
[   14.286386] e1000e 0000:00:19.0: irq 42 for MSI/MSI-X
...
[   41.143888] audit_printk_skb: 105 callbacks suppressed

1s zum Entpacken der initramfs mag ja noch gehen, aber 4s zum Mounten des rootfs?
Ich muss mal die Zeit zwischen Grub-Verlassen und Login-Screen messen, aber mit der "alten" Crucial M500 ging das gefuehlt doppelt so schnell.
Die neue SSD ist doppelt so gross und beherbergt in den vorderen zwei Partitionen noch Win7. Die Linux-Partition ist durch Umkopieren und nachtraegliches
Installieren des Grub drauf gekommen, aber das sollte doch der Start-Geschwindigkeit nicht schaden.

Gibt es ein Tool, mit dem man herausfinden kann, wo beim Booten die Zeit verbracht wird?

Gruss,
jal2
 
1,4 GHz? Ich glaube nicht, dass die SSD der Bottleneck bei deinem Problem ist.
 
1,4 GHz? Ich glaube nicht, dass die SSD der Bottleneck bei deinem Problem ist.
Naja, das ist ein C2D, ich hoffte schon, das er mit SSD schnell bootet. Zeit zwischen Verlassen des Grub bis zum Login-Screen (Xubuntu) sind ca. 20 Sekunden.

Ich kann nicht erkennen woher Du die 4s ableitest?! Mein X220 mit i7 2.8 GHz hat ein ähnliches Timing in den ersten Sekunden.
Aus der Differenz der aufeinanderfolgenden Zeitstempel (oder ist das zu einfach gedacht?):
Code:
[    3.408283] input: AlpsPS/2 ALPS DualPoint TouchPad as /devices/platform/i8042/serio1/input/input5
[    7.667406] EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: (null)
Unter Ubuntu gibt es das Tool bootchart --> http://wiki.ubuntuusers.de/BootChart
Danke, das probiere ich mal.
 
Genau. Da passiert eine Menge. Ich schlage vor, du machst mal einen trace des Kernels beim Booten. Wenn du die Millionen von Aufrufen durch hast, wirst du hoffentlich verstehen.
 
Zuletzt bearbeitet:
20 Sekunden ab Grub bis zur Anmeldung ist definitiv zu lange für die Hardware, das schafft ja man mit ein bisschen Glück noch mit ner HDD. Selbst mein X41 (1,5GHz Pentium M mit CF-Karte) ist da noch schneller. Hast du schon den Tipp von mornsgrans befolgt und das Alignment überprüft, nicht das beim rumkopieren die Partitionen falsch ausgerichtet wurden?
 
Genau. Da passiert eine Menge. Ich schlage vor, du machst mal einen trace des Kernels beim Booten. Wenn du die Millionen von Aufrufen durch hast, wirst du hoffentlich verstehen.
Wie mache ich einen Trace des Kernels beim Booten? Kann man ftrace ab Kernelstart aktivieren? Welche Konfiguration waere hier sinnvoll?
 
Wie mache ich einen Trace des Kernels beim Booten? Kann man ftrace ab Kernelstart aktivieren? Welche Konfiguration waere hier sinnvoll?

Davon würde ich absehen. Der Kernel braucht 1-3 Sek., um die Subsysteme (u.a. ATA/SCSI) zu laden, die restliche Zeit bis zum Mounten vom rootfs / ist durch das initramfs verursacht. Vollständiger dmesg-Log und Beschreibung des Setups wären hier interessant. Anscheinend bootest du ja von einer "normalen" Partition (kein lvm/crypto), sodass ggf. auf das initramfs verzichtet werden kann. Das holt aber höchstens 4-5 Sek. raus, da du die restliche Zeit (ab Zeitstempel 7.x oder 9.x, je nachdem, ob die Plymouth-Prozesse zum initramfs gehören) bereits in / verbringst.
 
Zuletzt bearbeitet:
Ich wollte damit lediglich ausdrücken, dass in der Zeit sehr wohl eine Menge passiert. Nicht jede Aktion wird (logischerweise) geloggt.

Jetzt, wo ich den Eingangspost nochmal gelesen habe, wird es wohl doch an der SSD liegen. Du hast also eine kleine M500 gegen eine große M500 getauscht und danach ist es langsam geworden? Dann würde ich, wie schon anfangs empfohlen, das Alignment überprüfen. Außerdem solltest du schauen, ob die Schnittstelle mit voller Geschwindigkeit läuft.
 
bei einem HDD / SSD tausch empfehle ich immer die biosdefaults zu laden, damit die aktuelle festblattengeometrie ins bios geschrieben wird,
denn da ist noch die alte, sollte das zwischenzeitlich nicht schon gemacht worden sein.
sich die wichtigen bioseinstellungen merken, speziel was nicht auf default steht.
 
Hast Du das Alignment überprüft?
Sieht IMHO gut aus - ich hatte zuerst Win7 auf der leeren SSD installiert, das Linux dann nachgeschoben:
Code:
Disk /dev/sda: 480.1 GB, 480103981056 bytes
255 heads, 63 sectors/track, 58369 cylinders, total 937703088 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x96afd301

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048      206847      102400    7  HPFS/NTFS/exFAT
/dev/sda2          206848   245759999   122776576    7  HPFS/NTFS/exFAT
/dev/sda3       245760000   909821951   332030976   83  Linux
/dev/sda4       909823998   937701375    13938689    5  Extended
Partition 4 does not start on physical sector boundary.
/dev/sda5       909824000   937701375    13938688   82  Linux swap / Solaris
Vollständiger dmesg-Log und Beschreibung des Setups wären hier interessant. Anscheinend bootest du ja von einer "normalen" Partition (kein lvm/crypto), sodass ggf. auf das initramfs verzichtet werden kann.
Das Setup ist ein X301 mit C2D SU9400 (2x1,4GHz), 6GB RAM und einer Crucial M500 480G im 1,8" Slot (mit Adapter). hdparm -tT sagt zur SSD:
Code:
/dev/sda:
 Timing cached reads:   3016 MB in  2.00 seconds = 1509.52 MB/sec
 Timing buffered disk reads: 738 MB in  3.01 seconds = 245.36 MB/sec
IMHO ein für SATA-2 normaler Wert.

Der komplette dmesg Output ist hier.

Du hast also eine kleine M500 gegen eine große M500 getauscht und danach ist es langsam geworden? Dann würde ich, wie schon anfangs empfohlen, das Alignment überprüfen. Außerdem solltest du schauen, ob die Schnittstelle mit voller Geschwindigkeit läuft.
Siehe oben und im dmesg Output steht:
Code:
[    2.012070] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Wegen der Geschwindigkeit kann mich meine Erinnerung auch täuschen - ich hatte die vorherige SSD (M500, 240GB) abwechselnd im X201s, T430 und X301 verbaut.
bei einem HDD / SSD tausch empfehle ich immer die biosdefaults zu laden, damit die aktuelle festblattengeometrie ins bios geschrieben wird,
denn da ist noch die alte, sollte das zwischenzeitlich nicht schon gemacht worden sein.
sich die wichtigen bioseinstellungen merken, speziel was nicht auf default steht.
Das habe ich probiert - hat leider nicht geholfen. Bis zum Login-Screen brauche ich immer noch 18-20 Sekunden (ab Grub-Menü gemessen).

EDIT: Aktueller Kernel ist der 3.13.0-35-generic (amd64). Die SSD ist eine Crucial CT480M500SD3 mit der Firmware MU05.
 
Zuletzt bearbeitet:
Ich paraphrasiere mal die dmesg-Ausgabe "inline", soweit relevant:

Code:
[    0.316784] Trying to unpack rootfs image as initramfs...
[    0.950186] Freeing initrd memory: 18720K (ffff880035b60000 - ffff880036da8000)
# "early userspace" (initramfs) geladen

# Kernel, nebenläufig: Laden der builtin-Module

[    1.429406] systemd-udevd[118]: starting version 204
# udev geladen, d.h. initramfs /init befindet sich definitiv in Ausführung

[    2.028086]  sda: sda1 sda2 sda3 sda4 < sda5 >
[    2.028936] sd 0:0:0:0: [sda] Attached SCSI disk
# rootfs-Device sda3 Kernel-seitig verfügbar

# initramfs macht ~5s Sek lang irgendetwas (**)

# initramfs: Mounten des rootfs /
[    7.085827] EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: (null)

# folgendes wird vmtl. in / ausgeführt (_typischerweise_ root/swap Init-Skripte o. upstart-Jobs)
[    7.533546] Adding 13938684k swap on /dev/sda5.  Priority:-1 extents:1 across:13938684k SSFS
[    7.580108] random: nonblocking pool is initialized
[    7.599951] EXT4-fs (sda3): re-mounted. Opts: errors=remount-ro
...
[    8.987481] systemd-udevd[392]: starting version 204
# ab hier definitiv in /

# 8.x-13.x: Laden von Modulen aus /lib/modules/<>
#  (14.x thinkpad_ec,tp_smapi,acpi_call durch TLP verursacht)

Meine Vermutungen für die 5s-"Pause": udev, Durchprobieren von sw-RAID/LVM/luks-Kombinationen, fsck.

Beobachtung: Boot von reg. Partition, alle dafür notwendigen Module sind im Kernel integriert (ref. hier); kein implizites (mount-verursachtes) fsck, anscheinend kein Laden von Modulen aus /lib/ im initramfs.

Alles in allem teile ich deine Grundannahme, dass die 4..5 Sek. bis zum Mounten des rootfs für dieses System verschenkte Zeit sind. Du kannst (a) ganz ohne initramfs booten oder (b) das initramfs durch leichtere Alternativen (better-initramfs, liram, ...) ersetzen, erwartetes Optimierungspotenzial liegt bei 3-5 Sek. In beiden Fällen verlierst du plymouth (Bootsplash) und der Verwaltungsaufwand erhöht sich (bei b mehr als a). Bei a verlierst du außerdem die Möglichkeit, das rootfs per UUID anzugeben und musst stattdessen auf PARTUUID zurückgreifen:
Code:
# PARTUUID=<disk identifier (siehe fdisk -l)>-<Part-Nr., zwei Ziffern>
root=PARTUUID=96afd301-03

Das gilt für MBR-partitionierte Disks (hier der Fall), bei GPT hilft blkid.


Die Bootzeit nach dem initramfs lässt sich im Allgemeinen durch das Deaktivieren nicht benötigter Dienste / Autostart-Programme reduzieren.

Bevor du irgendwas optimierst, solltest du allerdings noch bootchart sowie /var/log befragen und einmal ohne splash/quiet-Parameter booten.

---

hdparm umgeht Partionierung/Dateisystem und sagt damit nicht viel aus. Mit einem X200T (Core2 Solo 1.4, ocz Vertex 2 120G) komme ich übrigens auf ähnliche Werte (~200 bei "Timing buffered disk reads").
Ein einfacher Test wäre
Code:
# Lesen
sudo -- sh -c "echo 3 > /proc/sys/vm/drop_caches && dd if=/dev/sda3 of=/dev/null conv=notrunc bs=200M count=10"

# Schreiben
dd if=/dev/zero of=~/data.img conv=fdatasync,notrunc bs=200M count=10 && rm -- ~/data.img

Für notwendig halte ich das nicht, schaden kann's aber auch nicht, zumindest der Lesetest. Bei der Gelegenheit kannst du gleich testen, ob es einen erheblichen Unterschied in Abh. des APM-Levels gibt - reine Neugier, war nämlich beim Vorgängermodell m4 so:

Code:
sudo -- hdparm -B 1 /dev/sda
<Schreibtest>

sudo -- hdparm -B 128 /dev/sda
<Schreibtest>

sudo -- hdparm -B 255 /dev/sda
<Schreibtest>
 
Ach, das hat ja schon systemd. Dann gibt es (zumindest in höheren Abstraktionsebenen)
Code:
systemd-analyze blame
und
Code:
systemd-analyze plot > boot.svg
Insbesondere letzteres könnte hilfreich beim Debuggen sein.
 
Das ist nur udev, systemd sähe in dmesg so aus:
Code:
[    2.534708] systemd[1]: systemd 215 running in system mode. (+PAM +AUDIT -SELINUX +IMA -SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ +SECCOMP -APPARMOR)
 
bei ubuntu ist systemd zwar installiert und teile davon kommen beim booten zum tragen, doch die hauptarbeit macht immer noch upstart. daher funktionieren die beiden systemd-befehle leider nicht. der wechsel von upstart auf systemd steht noch aus.
 
  • ok1.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen
Zurück
Oben