Ich habe bisher immer beim mounten von SSDs fstab-Einträge trim, noatime, nodiratime angegeben. Ist das bei Leap eigentlich noch nötig? Wenn ja, warum erkennt Leap nicht eine SSD und setzt diese Parameter nicht automatisch? Oder sie sind nicht mehr nötig, kann ja sein. Oder benötigt das Dateisystem BTRFS diese Parameter nicht? Dennoch müsste ich meine "alte" EXT4-home-Partition dann wenigstens mi diesen Parametern einhängen, oder?
Sind bei der Verwendung von SSDs noch spezielle fstab-Eiträge nötig?
- pschulze59
- Erledigt
Hinweis: In dem Thema Sind bei der Verwendung von SSDs noch spezielle fstab-Eiträge nötig? gibt es 10 Antworten auf 2 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
-
-
-
Das auch noch:
ZitatRULE 7: I/O SCEDULER TO DEADLINE
By default, openSUSE still uses the “old” I/O scheduler CFQ, which is only fine for conventional hard disks but not for SSD’s, which are being slowed down. So it’s wise when you have an SSD in your machine, to change the scheduler to Deadline, which is good for both SSD’s and conventional platter hard disks.
You can realize this by changing the boot parameters of Grub. You can do that as follows.
Check your current scheduler as follows:
cat /sys/block/sda/queue/scheduler
(if your drive isn’t sda, change the line accordingly)
The output will probably be:
noop deadline [cfq]
Which means: cfq is active, but noop and deadline are also supported.
Now type:
sudo nano /etc/default/grub
Find the line: GRUB_CMDLINE_LINUX_DEFAULT=
This line may look like this (example):
GRUB_CMDLINE_LINUX_DEFAULT=” resume=/dev/sda1 splash=silent quiet showopts”And add the option elevator=deadline.
Example:
GRUB_CMDLINE_LINUX_DEFAULT=” resume=/dev/sda1 splash=silent quiet showopts elevator=deadline”Save the modified file and close it.
Now update Grub for this change. In the terminal:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
-
Das ganze Genödel bezüglich SSD halte ich für völlig überflüssig.
Kein Normaluser schafft es eine aktuelle SSD an die werksseitig vorgesehene Lebensdauergrenze zu bringen. -
Das ganze Genödel bezüglich SSD halte ich für völlig überflüssig.
Kein Normaluser schafft es eine aktuelle SSD an die werksseitig vorgesehene Lebensdauergrenze zu bringen.
Sehe ich genauso, nur der Parameter deadline
sollte eingetragen werden. -
-
Danke für die Antworten, aber ich bin "a little bit confused".
Ich versuche mal zu sortieren:
1.
fstab-Einträge discard, noatime, nodiratime haltet ihr für unnötig, da man "... ohnehin nicht die Lebensdauer einer SSD ausnutzt ..." (Zitat sinngemäß)Der von Sauerland gepostete Artikel sagt dazu was anderes.
Aber egal, ob diese Parameter nun Sinn machen oder nicht (sie schaden jedenfalls nicht), bleibt für mich noch eine Frage offen: Das Standardsystem richtet eine Unmenge an Subvolumes ein. Sollte man dann konsequenterweise diese Parameter auch für jedes der Subvolumes angeben (sofern man sie angeben will)? Meiner Meinung nach gibt es da je einige, bei denen viele Schreib- und Löschvorgänge laufen, also gerade discard Sinn machen würde.
2.
Ihr haltet den GRUB-Parameter elevator=deadline für " ...auf jeden Fall sinnvoll... ". Mal davon abgesehen, dass ich dessen Sinn nicht wirklich verstanden habe, ist mir noch unklar, was die eckigen Klammern bedeuten, wenn ich mir mit "cat /sys/block/sda/queue/scheduler" den Status anzeigen lasse. Bei mir liefert die Anzeige nämlich ein deadline in eckigen Klammern. Ist der Parameter damit nun gesetzt oder noch nicht?
Falls ja, warum enthält meine /etc/default/grub dann keinen Parameter "deadline"?Vielleicht kann mir jemand noch diese zwei Fragen beantworten.
Danke!
-
Man kann es kurz machen. Der von Sauerland gepostete Artikel ist aus dem Jahre 2013. Wir haben 2016. Das sind in der Computertechnik Jahrzehnte.
Ein trim ist für SSD nicht mehr nötig, da die heutigen SSD-Controller ihren Job besser erledigen als vor 3 Jahren. Wir hatten dazu vor längerer Zeit schon einmal eine ausführliche Diskussion hier im Forum.Zu deiner 2. Frage findest du genug Antworten im Web.
-
fstab-Einträge discard, noatime, nodiratime haltet ihr für unnötig, da man "... ohnehin nicht die Lebensdauer einer SSD ausnutzt ..." (Zitat sinngemäß)
Der von Sauerland gepostete Artikel sagt dazu was anderes.
Aber egal, ob diese Parameter nun Sinn machen oder nicht (sie schaden jedenfalls nicht), bleibt für mich noch eine Frage offen: Das Standardsystem richtet eine Unmenge an Subvolumes ein. Sollte man dann konsequenterweise diese Parameter auch für jedes der Subvolumes angeben (sofern man sie angeben will)? Meiner Meinung nach gibt es da je einige, bei denen viele Schreib- und Löschvorgänge laufen, also gerade discard Sinn machen würde.
Man kann noatime, discard, nodiratime eintragen, muss es aber nicht.
Und wenn dann bitte nur für "richtige" Mountpoints machen, nicht für temporäre Filesysteme.
Siehe z.B. mit:
oder
Für swap natürlich sowieso nicht.......Ihr haltet den GRUB-Parameter elevator=deadline für " ...auf jeden Fall sinnvoll... ". Mal davon abgesehen, dass ich dessen Sinn nicht wirklich verstanden habe, ist mir noch unklar, was die eckigen Klammern bedeuten, wenn ich mir mit "cat /sys/block/sda/queue/scheduler" den Status anzeigen lasse. Bei mir liefert die Anzeige nämlich ein deadline in eckigen Klammern. Ist der Parameter damit nun gesetzt oder noch nicht?
Falls ja, warum enthält meine /etc/default/grub dann keinen Parameter "deadline"?
Wenn der in eckigen Klammern erscheint, ist der gesetzt, da braucht es keinen Eintrag mehr.
Das liegt am Kernel, was der Kernel benutzt, bei Dir halt ein anderer Parameter als bei mir auf der 13.2, kann auch sein das das mit Leap geändert wurde.Übrigens gibt es mittlerweile so viel gegenteilige Anleitungen.............
-
Alles klar, da sich diese Fragen auf meinen Leap-Laptop bezogen, erklärt sich, dass "deadline" aktiv ist, da der Kernel die SSD-Erkennung mittlerweile leisten kann.
Insofern scheint ab Leap bezüglich spezieller SSD-Parameter tatsächlich nichts mehr notwendig zu sein.Danke für die Beiträge.