Am 13.01.2019 um 15:01 schrieb Bernhard Junk:

Hallo Zusammen und ein frohes neues Jahr.

Das stimmt nur bedingt: Das stimmt gar nicht !!!

Ich ahbe ein älteres ASUS-Board ( 2005 ) mit Sata II. Daran habe ich eine SSD von Kingston mit 250GB angeschlossen. Läuft super! Bernd

Klar, warum auch nicht. Habe selber so eine Konfiguration Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Am 13.01.2019 um 18:00 schrieb Herbert Albert:

Am Sonntag, 13. Januar 2019, 15:20:27 CET schrieb Manfred Kreisl:

...

Am 13.01.2019 um 15:01 schrieb Bernhard Junk:

...

Hallo Zusammen und ein frohes neues Jahr.

...

Das stimmt nur bedingt: Das stimmt gar nicht !!!

...

Ich ahbe ein älteres ASUS-Board ( 2005 ) mit Sata II. Daran habe ich eine SSD von Kingston mit 250GB angeschlossen. Läuft super! Bernd

Klar, warum auch nicht. Habe selber so eine Konfiguration

Manfred Hallo Manfred,

die SATA-SSD wird in den Desktop ja nur an das SATA-Kabel angeschlossen. Für was ist eigentlich der Steckfuß daneben?

Hmmm, welchen meinst Du? Da gibt's zwei Anschlüsse, der eine ist für die Daten (der Schmalere von beiden), der andere für die Power. Falls da nix stecken solle, wundert nichts dass die SSD nicht erkannt wird. Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Am 13.01.2019 um 18:12 schrieb Herbert Albert:

Am Sonntag, 13. Januar 2019, 18:04:12 CET schrieb Manfred Kreisl:

...

Am 13.01.2019 um 18:00 schrieb Herbert Albert:

...

Am Sonntag, 13. Januar 2019, 15:20:27 CET schrieb Manfred Kreisl:

...

Am 13.01.2019 um 15:01 schrieb Bernhard Junk:

...

Hallo Zusammen und ein frohes neues Jahr.

...

Das stimmt nur bedingt: Das stimmt gar nicht !!!

...

Ich ahbe ein älteres ASUS-Board ( 2005 ) mit Sata II. Daran habe ich eine SSD von Kingston mit 250GB angeschlossen. Läuft super! Bernd

Klar, warum auch nicht. Habe selber so eine Konfiguration

Manfred

Hallo Manfred,

die SATA-SSD wird in den Desktop ja nur an das SATA-Kabel angeschlossen. Für was ist eigentlich der Steckfuß daneben?

Hmmm, welchen meinst Du? Da gibt's zwei Anschlüsse, der eine ist für die Daten (der Schmalere von beiden), der andere für die Power. Falls da nix stecken solle, wundert nichts dass die SSD nicht erkannt wird.

Manfred stimmt. Habe die SSD nun an einen Multi-Adapter USB-SATA angeschlossen. Den breiten für Power, den schmalen für Daten. Da rührt sich dann aber leider auch nichts. Und dieser Adapter hat nicht noch einen extra Anschluss für den Strom?

Oder, eventuell kann das Motherboard mit diesem Adapter nichts anfangen Manfred

Herbert

-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Am Sonntag, 13. Januar 2019, 18:51:00 CET schrieb Herbert Albert:

Am Sonntag, 13. Januar 2019, 18:22:25 CET schrieb Manfred Kreisl:

...

Am 13.01.2019 um 18:12 schrieb Herbert Albert:

...

Am Sonntag, 13. Januar 2019, 18:04:12 CET schrieb Manfred Kreisl:

...

Am 13.01.2019 um 18:00 schrieb Herbert Albert:

...

Am Sonntag, 13. Januar 2019, 15:20:27 CET schrieb Manfred Kreisl:

...

Am 13.01.2019 um 15:01 schrieb Bernhard Junk: > Hallo Zusammen und ein frohes neues Jahr.

> Das stimmt nur bedingt: Das stimmt gar nicht !!!

> Ich ahbe ein älteres ASUS-Board ( 2005 ) mit Sata II. Daran habe ich > eine SSD von Kingston mit 250GB angeschlossen. Läuft super! > Bernd

Klar, warum auch nicht. Habe selber so eine Konfiguration

Manfred

Hallo Manfred,

die SATA-SSD wird in den Desktop ja nur an das SATA-Kabel angeschlossen. Für was ist eigentlich der Steckfuß daneben?

Hmmm, welchen meinst Du? Da gibt's zwei Anschlüsse, der eine ist für die Daten (der Schmalere von beiden), der andere für die Power. Falls da nix stecken solle, wundert nichts dass die SSD nicht erkannt wird.

Manfred

stimmt. Habe die SSD nun an einen Multi-Adapter USB-SATA angeschlossen. Den breiten für Power, den schmalen für Daten. Da rührt sich dann aber leider auch nichts.

Und dieser Adapter hat nicht noch einen extra Anschluss für den Strom?

Oder, eventuell kann das Motherboard mit diesem Adapter nichts anfangen

Manfred

...

Herbert

Doch hat er, nur wird die SSD nicht erkannt. Mit einer normalen SATA-Platte geht alles. Habe aber mit der Erfahrung die SSD nochmals in den PC eingebaut, wo sie eigentlich hin soll. Nun mit Strom, und der alte Spruch hat sich bewahrheitet: Im Prinzip geht alles, doch ohne Strom geht nichts ;-)

Warum sie an den USB-Multiadapter nicht geht, keine Ahnung, ist aber im Moment nicht das Thema.

Herbert jetzt muss ich möglichst schnell das alte openSuSE 12.3 (160GB HDD) auf die SSD (250GB) bringen und das ganze bootfähig machen. In dem Artikel von Sebastian Siebert (https://www.sebastian-siebert.de/2013/09/22/opensuse-umzug-von-der-festplatt...) treten für mich zwei Fragen auf: Ist der Kernel 3.7.10 (i686) geeignet und was hat es mit dem in dem Artikel erwähnten TRIM und Aktivierung der Host Protected Area (HPA) auf sich? Als Dateisystem würde ich wie gehabt ext4 nehmen.

Herbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Zitat von Manfred Kreisl :

Am 13.01.2019 um 19:22 schrieb Herbert Albert: [ ... ]

...

...

Herbert jetzt muss ich möglichst schnell das alte openSuSE 12.3 (160GB HDD) auf die SSD (250GB) bringen und das ganze bootfähig machen. In dem Artikel von Sebastian Siebert (https://www.sebastian-siebert.de/2013/09/22/opensuse-umzug-von-der-festplatt...) treten für mich zwei Fragen auf: Ist der Kernel 3.7.10 (i686) geeignet und was hat es mit dem in dem Artikel erwähnten TRIM und Aktivierung der Host Protected Area (HPA) auf sich? Als Dateisystem würde ich wie gehabt ext4 nehmen.

Debian hat TRIM Support ab Kernel 3.2, also kann man wohl davon ausgehen, dass openSUSE das im 3.7 auch drinnen hat.

HPA - kannste getrost ignorieren. Alle aktuellen SSD's haben von Hause aus solch einen Bereich aktiviert. Bitte korrigiert mich, falls ich mich da irre.

Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Der Bequemlichkeit halber habe ich die Partitionen exakt wie auf der HDD auf der SSD eingerichtet (mit gparted. Habe von eine DVD mit Xubuntu gebootet)). Anschließend die Partitionen gemountet (Quelle mit -o ro, Ziel mit -o noatime,nodiratime,discard). Ob die mount flags, wie bei Sebastian Siebert beschrieben sein müssen, weiß ich nicht. Dachte es war bei ihm auch eine OS 12.3 und bei mir eben auch. Danach alles per rsync umgezogen und die fstab und grub2 Dateien angepasst. Den String des SSD-Namen habe ich per ls -l /dev/disk/by-id ausgeben lassen und im Editor per suchen und ersetzen (ohne -partX) ausgetauscht. Anschließend chroot etc. Leider bootet die SSD nicht. Bleibe in der Konsole hängen mit der Aufforderung das Root-Passwort einzugeben. Mir ist aufgefallen, dass es in /boot neben grub2 auch ein grub2-efi (oder s.ä. gibt, sitze jetzt nicht vor dem Rechner). Habe ich da die falschen Dateien editiert? Herbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Am 14.01.2019 um 19:59 schrieb Herbert Albert:

Am Montag, 14. Januar 2019, 07:21:10 CET schrieb h.albert@odn.de:

...

Zitat von Manfred Kreisl :

...

Am 13.01.2019 um 19:22 schrieb Herbert Albert: [ ... ]

...

...

Herbert

jetzt muss ich möglichst schnell das alte openSuSE 12.3 (160GB HDD) auf die SSD (250GB) bringen und das ganze bootfähig machen. In dem Artikel von Sebastian Siebert (https://www.sebastian-siebert.de/2013/09/22/opensuse-umzug-von-der-festp latte-zur-ssd/) treten für mich zwei Fragen auf: Ist der Kernel 3.7.10 (i686) geeignet und was hat es mit dem in dem Artikel erwähnten TRIM und Aktivierung der Host Protected Area (HPA) auf sich? Als Dateisystem würde ich wie gehabt ext4 nehmen.

Debian hat TRIM Support ab Kernel 3.2, also kann man wohl davon ausgehen, dass openSUSE das im 3.7 auch drinnen hat.

HPA - kannste getrost ignorieren. Alle aktuellen SSD's haben von Hause aus solch einen Bereich aktiviert. Bitte korrigiert mich, falls ich mich da irre.

Manfred

Der Bequemlichkeit halber habe ich die Partitionen exakt wie auf der HDD auf der SSD eingerichtet (mit gparted. Habe von eine DVD mit Xubuntu gebootet)). Anschließend die Partitionen gemountet (Quelle mit -o ro, Ziel mit -o noatime,nodiratime,discard). Ob die mount flags, wie bei Sebastian Siebert beschrieben sein müssen, weiß ich nicht. Dachte es war bei ihm auch eine OS 12.3 und bei mir eben auch. Danach alles per rsync umgezogen und die fstab und grub2 Dateien angepasst. Den String des SSD-Namen habe ich per ls -l /dev/disk/by-id ausgeben lassen und im Editor per suchen und ersetzen (ohne -partX) ausgetauscht. Anschließend chroot etc. Leider bootet die SSD nicht. Bleibe in der Konsole hängen mit der Aufforderung das Root-Passwort einzugeben. Mir ist aufgefallen, dass es in /boot neben grub2 auch ein grub2-efi (oder s.ä. gibt, sitze jetzt nicht vor dem Rechner). Habe ich da die falschen Dateien editiert?

Herbert

Hallo,

ich habe jetzt nochmals das Ursprungssystem hochgefahren und die SSD ist auch im System. Ein fdisk -l zeigt alle Partitionen an. Versuche ich eine zu mounten, z.B. mount /dev/sdb6 /mnt erscheint: mount: wrong fs type, bad option, bad superblock on /dev/sdb6 missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so

dmesg | tail sagt: EXT4-fs (sdb6): error loading journal

Würde mal sagen, da ist beim Anlegen der Dateisysteme und beim Anschließenden kopieren was schief gelaufen Nur mal eine Frage, möchtest Du die HD weiter im System belassen? Denn wenn nicht, würde ich zumindest die gesamte HD mittels dd klonen. Das geht aber nur dann problemlos, wenn die Quelle nicht mehr im System verbleibt, da die UUID's ja identisch sind - und dann wäre das reinste Chaos vorprogrammiert. Eine Anpassung der Partitionsgrößen kann man hinterher immer noch machen, schlimmstenfalls mit GParted Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Am 14.01.2019 um 21:10 schrieb Herbert Albert:

Am Montag, 14. Januar 2019, 20:31:46 CET schrieb Manfred Kreisl:

...

Am 14.01.2019 um 19:59 schrieb Herbert Albert:

...

Am Montag, 14. Januar 2019, 07:21:10 CET schrieb h.albert@odn.de:

...

Zitat von Manfred Kreisl :

...

Am 13.01.2019 um 19:22 schrieb Herbert Albert: [ ... ]

...

> Herbert

jetzt muss ich möglichst schnell das alte openSuSE 12.3 (160GB HDD) auf die SSD (250GB) bringen und das ganze bootfähig machen. In dem Artikel von Sebastian Siebert (https://www.sebastian-siebert.de/2013/09/22/opensuse-umzug-von-der-fes tp latte-zur-ssd/) treten für mich zwei Fragen auf: Ist der Kernel 3.7.10 (i686) geeignet und was hat es mit dem in dem Artikel erwähnten TRIM und Aktivierung der Host Protected Area (HPA) auf sich? Als Dateisystem würde ich wie gehabt ext4 nehmen.

Debian hat TRIM Support ab Kernel 3.2, also kann man wohl davon ausgehen, dass openSUSE das im 3.7 auch drinnen hat.

HPA - kannste getrost ignorieren. Alle aktuellen SSD's haben von Hause aus solch einen Bereich aktiviert. Bitte korrigiert mich, falls ich mich da irre.

Manfred

Der Bequemlichkeit halber habe ich die Partitionen exakt wie auf der HDD auf der SSD eingerichtet (mit gparted. Habe von eine DVD mit Xubuntu gebootet)). Anschließend die Partitionen gemountet (Quelle mit -o ro, Ziel mit -o noatime,nodiratime,discard). Ob die mount flags, wie bei Sebastian Siebert beschrieben sein müssen, weiß ich nicht. Dachte es war bei ihm auch eine OS 12.3 und bei mir eben auch. Danach alles per rsync umgezogen und die fstab und grub2 Dateien angepasst. Den String des SSD-Namen habe ich per ls -l /dev/disk/by-id ausgeben lassen und im Editor per suchen und ersetzen (ohne -partX) ausgetauscht. Anschließend chroot etc. Leider bootet die SSD nicht. Bleibe in der Konsole hängen mit der Aufforderung das Root-Passwort einzugeben. Mir ist aufgefallen, dass es in /boot neben grub2 auch ein grub2-efi (oder s.ä. gibt, sitze jetzt nicht vor dem Rechner). Habe ich da die falschen Dateien editiert?

Herbert

Hallo,

ich habe jetzt nochmals das Ursprungssystem hochgefahren und die SSD ist auch im System. Ein fdisk -l zeigt alle Partitionen an. Versuche ich eine zu mounten, z.B. mount /dev/sdb6 /mnt erscheint: mount: wrong fs type, bad option, bad superblock on /dev/sdb6 missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so

dmesg | tail sagt: EXT4-fs (sdb6): error loading journal

Würde mal sagen, da ist beim Anlegen der Dateisysteme und beim Anschließenden kopieren was schief gelaufen

Nur mal eine Frage, möchtest Du die HD weiter im System belassen?

Denn wenn nicht, würde ich zumindest die gesamte HD mittels dd klonen. Das geht aber nur dann problemlos, wenn die Quelle nicht mehr im System verbleibt, da die UUID's ja identisch sind - und dann wäre das reinste Chaos vorprogrammiert.

Eine Anpassung der Partitionsgrößen kann man hinterher immer noch machen, schlimmstenfalls mit GParted

Manfred Hallo Manfred,

ich würde die Platte als Backup im Rechner lassen, allerdings stromlos. Die Partitionen habe ich jetzt mal mit gparted gecheckt. Da kam einen Meldung, ist leider schon wieder verschwunden. Jedenfalls konnte ich unter Xbuntu danach die Partition einbinden. Mit dem OS 12.3 klappt es nicht, booten auch nicht. Bin dann nochmals mit einer GParted-DVD hochgefahren, da kommt beim Überprüfen die Fehlermeldung "Beim Anwenden der Operation trat ein Fehler auf". Anscheinend hat Xbundu 18 ein neueres geparted. Ich erinnere mich dünkel, dass sich da beim Anlegen eines ext4 FS irgendwelche default Optionen geändert haben. Möglicherweise liegt es daran, aber nagel mich daran jetzt nicht fest (ich bin halt kein aktiver ext4 Benutzer ;))

Wie hast Du deine SSD in die fstab eingetragen, so wie bei Sebastian Siebert beschrieben? Mit: acl,user_xattr,noatime,nodiratime,discard

Nur zum Teil, da ich kein EXT4, sondern BTRFS verwende. noatime und nodiratime ist immer gut, über die Option discard gibt es geteilte Meinungen, die Tendenz geht aber dazu, diese Option nicht mehr zu verwenden.

Werde die Partitionen wohl nochmals erzeugen müssen, vielleicht am besten mit Yast mit dem original OS 12.3 der HDD. Danach nochmals mit rsync kopieren.

Das ist bestimmt besser, das 'alte' 12.3 dafür zu verwenden Viel Erfolg Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Am 14.01.19 um 22:11 schrieb Herbert Albert:

Hier steht auch etwas dazu. Daraus würde ich entnehmen, es muss eingeschaltet bzw. in der fstab angegeben werden. In der Page wird auch darauf hingewiesen, dass für OS 12.3 discard in die fstab soll. https://www.tweakhound.com/2013/03/25/opensuse-12-3-tips-tricks-and-tweaks/

Oh dear! von March 25, 2013, 13:06(EST) By Eric (a.k.a. TweakHound hier funktioniert, unter Tumbleweed, Leap 15 und Kubuntu 18.04.1, leicht angepasst, das Script fstrim in /etc/cron.weekly/ #!/bin/sh # cron.weekly # trim all mounted file systems which support it fstrim -av anacron sollte auch installiert sein. zum Testen genügt in der Konsole als root: fstrim -av siehe auch man fstrim Peter

Herbert

-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Am Montag, 14. Januar 2019, 21:31:22 CET schrieb Manfred Kreisl:

Am 14.01.2019 um 21:10 schrieb Herbert Albert:

...

Am Montag, 14. Januar 2019, 20:31:46 CET schrieb Manfred Kreisl:

...

Am 14.01.2019 um 19:59 schrieb Herbert Albert:

...

Am Montag, 14. Januar 2019, 07:21:10 CET schrieb h.albert@odn.de:

...

Zitat von Manfred Kreisl :

...

Am 13.01.2019 um 19:22 schrieb Herbert Albert: [ ... ]

>> Herbert > > jetzt muss ich möglichst schnell das alte openSuSE 12.3 (160GB HDD) > auf > die > SSD (250GB) bringen und das ganze bootfähig machen. In dem Artikel > von > Sebastian Siebert > (https://www.sebastian-siebert.de/2013/09/22/opensuse-umzug-von-der-f > es > tp > latte-zur-ssd/) treten für mich zwei Fragen auf: > Ist der Kernel 3.7.10 (i686) geeignet und was hat es mit dem in dem > Artikel > erwähnten TRIM und Aktivierung der Host Protected Area (HPA) auf > sich? > Als > Dateisystem würde ich wie gehabt ext4 nehmen.

Debian hat TRIM Support ab Kernel 3.2, also kann man wohl davon ausgehen, dass openSUSE das im 3.7 auch drinnen hat.

HPA - kannste getrost ignorieren. Alle aktuellen SSD's haben von Hause aus solch einen Bereich aktiviert. Bitte korrigiert mich, falls ich mich da irre.

Manfred

Der Bequemlichkeit halber habe ich die Partitionen exakt wie auf der HDD auf der SSD eingerichtet (mit gparted. Habe von eine DVD mit Xubuntu gebootet)). Anschließend die Partitionen gemountet (Quelle mit -o ro, Ziel mit -o noatime,nodiratime,discard). Ob die mount flags, wie bei Sebastian Siebert beschrieben sein müssen, weiß ich nicht. Dachte es war bei ihm auch eine OS 12.3 und bei mir eben auch. Danach alles per rsync umgezogen und die fstab und grub2 Dateien angepasst. Den String des SSD-Namen habe ich per ls -l /dev/disk/by-id ausgeben lassen und im Editor per suchen und ersetzen (ohne -partX) ausgetauscht. Anschließend chroot etc. Leider bootet die SSD nicht. Bleibe in der Konsole hängen mit der Aufforderung das Root-Passwort einzugeben. Mir ist aufgefallen, dass es in /boot neben grub2 auch ein grub2-efi (oder s.ä. gibt, sitze jetzt nicht vor dem Rechner). Habe ich da die falschen Dateien editiert?

Herbert

Hallo,

ich habe jetzt nochmals das Ursprungssystem hochgefahren und die SSD ist auch im System. Ein fdisk -l zeigt alle Partitionen an. Versuche ich eine zu mounten, z.B. mount /dev/sdb6 /mnt erscheint: mount: wrong fs type, bad option, bad superblock on /dev/sdb6

missing

...

...

codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so

dmesg | tail sagt: EXT4-fs (sdb6): error loading journal

Würde mal sagen, da ist beim Anlegen der Dateisysteme und beim Anschließenden kopieren was schief gelaufen

Nur mal eine Frage, möchtest Du die HD weiter im System belassen?

Denn wenn nicht, würde ich zumindest die gesamte HD mittels dd klonen. Das geht aber nur dann problemlos, wenn die Quelle nicht mehr im System verbleibt, da die UUID's ja identisch sind - und dann wäre das reinste Chaos vorprogrammiert.

Eine Anpassung der Partitionsgrößen kann man hinterher immer noch machen, schlimmstenfalls mit GParted

Manfred

Hallo Manfred,

ich würde die Platte als Backup im Rechner lassen, allerdings stromlos. Die Partitionen habe ich jetzt mal mit gparted gecheckt. Da kam einen Meldung, ist leider schon wieder verschwunden. Jedenfalls konnte ich unter Xbuntu danach die Partition einbinden. Mit dem OS 12.3 klappt es nicht, booten auch nicht. Bin dann nochmals mit einer GParted-DVD hochgefahren, da kommt beim Überprüfen die Fehlermeldung "Beim Anwenden der Operation trat ein Fehler auf". Anscheinend hat Xbundu 18 ein neueres geparted.

Ich erinnere mich dünkel, dass sich da beim Anlegen eines ext4 FS irgendwelche default Optionen geändert haben. Möglicherweise liegt es daran, aber nagel mich daran jetzt nicht fest (ich bin halt kein aktiver ext4 Benutzer ;))

...

Wie hast Du deine SSD in die fstab eingetragen, so wie bei Sebastian Siebert beschrieben? Mit: acl,user_xattr,noatime,nodiratime,discard

Nur zum Teil, da ich kein EXT4, sondern BTRFS verwende. noatime und nodiratime ist immer gut, über die Option discard gibt es geteilte Meinungen, die Tendenz geht aber dazu, diese Option nicht mehr zu verwenden.

...

Werde die Partitionen wohl nochmals erzeugen müssen, vielleicht am besten mit Yast mit dem original OS 12.3 der HDD. Danach nochmals mit rsync kopieren. Das ist bestimmt besser, das 'alte' 12.3 dafür zu verwenden

Viel Erfolg

Manfred Also die Partitionen sind angelegt und auch die Dateien kopiert. Nun zu der Anpassung von grub2 Dazu muss ich doch eigentlich kein Rettungssystem nehmen, oder? Ich kann doch auch mit der OS 12.3 von der HDD hochfahren, die SDD-Partitionen auf einen Mount-Point mounten und dann die mount --bind, chroot usw. ausführen. Oder geht das nicht?

Herbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Am Montag, 14. Januar 2019, 23:47:14 CET schrieb Manfred Kreisl:

Am 14.01.2019 um 22:33 schrieb Herbert Albert:

...

...

Nur zum Teil, da ich kein EXT4, sondern BTRFS verwende. noatime und nodiratime ist immer gut, über die Option discard gibt es geteilte Meinungen, die Tendenz geht aber dazu, diese Option nicht mehr zu verwenden.>>

...

Werde die Partitionen wohl nochmals erzeugen müssen, vielleicht am besten mit Yast mit dem original OS 12.3 der HDD. Danach nochmals mit rsync kopieren.

Das ist bestimmt besser, das 'alte' 12.3 dafür zu verwenden

Viel Erfolg

Manfred

Also die Partitionen sind angelegt und auch die Dateien kopiert. Nun zu der Anpassung von grub2 Dazu muss ich doch eigentlich kein Rettungssystem nehmen, oder? Ich kann doch auch mit der OS 12.3 von der HDD hochfahren, die SDD-Partitionen auf einen Mount-Point mounten und dann die mount --bind, chroot usw. ausführen. Oder geht das nicht?

Doch, sicher geht das.

Manfred Also irgendwie ist da der Wurm drin.

Jetzt habe ich die Partitionen mit OS 12.3 angelegt, Daten kopiert, fstab, / etc/sysconfig/bootloader editiert und dann doch die alte Platte abgeklemmt und mit einem Rescue OS 12.3 i686 gebootet. Danach mount -o noatime,nodiratime,discard /dev/sda5 /mnt mount -o noatime,nodiratime,discard /dev/sda1 /mnt/boot mount -o noatime,nodiratime,discard /dev/sda6 /mnt/home mount --bind /dev /mnt/dev mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys chroot /mnt /bin/bash -> funktioniert nicht /bin/bash wird als Verzeichnis abgelehnt, dann nur chroot /mnt grub2-mkconfig -o /boot/grub2/grub.cfg Da kommt am Schluss Error: opening path /mounts/instsys/sys/block grub2-install /dev/sda mkinitrd Da kommt There are an error generating the initrd (1) Was mache ich falsch? Herbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Am 15.01.2019 um 19:23 schrieb Herbert Albert: [ ... ]

grub2-install /dev/sda

mkinitrd Da kommt There are an error generating the initrd (1)

Was mache ich falsch?

Könnte sein, dass mkinitrd so nicht funktioniert, da die Kernel-Version von der DVD nicht mit der Kernel-Version auf der Platte übereinstimmt. Die Module zum gerade laufenden Kernel können also nicht gefunden werden, obgleich die man-page zu mkinitrd im Abschnitt RECOVERY nichts dergleichen erwähnt. Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Am 15.01.2019 um 21:22 schrieb Herbert Albert:

Am Dienstag, 15. Januar 2019, 20:05:03 CET schrieb Manfred Kreisl:

...

Am 15.01.2019 um 19:23 schrieb Herbert Albert: [ ... ]

...

grub2-install /dev/sda

mkinitrd Da kommt There are an error generating the initrd (1)

Was mache ich falsch?

Könnte sein, dass mkinitrd so nicht funktioniert, da die Kernel-Version von der DVD nicht mit der Kernel-Version auf der Platte übereinstimmt. Die Module zum gerade laufenden Kernel können also nicht gefunden werden, obgleich die man-page zu mkinitrd im Abschnitt RECOVERY nichts dergleichen erwähnt.

Manfred nein das war es nicht.

Mir hat das Bios einen Streich gespielt, den ich nur nicht mehr logisch nachvollziehen kann. Obwohl ich von der original HDD das Datenkabel abgezogen habe sind im Bios beide Platten, die HDD und die SSD bekannt. Dann habe ich irgendwie eine Mix der Partitionen hinbekommen, jedenfalls waren die Einträge in fstab und grub2 genau verkehrt herum. Klingt äusserst seltsam ...

Nun nochmals das ganze mit abgezogen Daten- und Stromkabel, und die Welt ist in Ordnung. Eine allzu große Performancesteigerung merke ich nicht. Booten geht schneller, einige Anwendungen laden schneller (z.B. LibreOffice), andere nicht so sehr. Ist halt eine alte Kiste mit 2GB RAM und AMD Athlon 64 3200+

Aber nun ist die SSD drin und da bleibt sie auch erst einmal.

Kannst ja mal testen, wie schnell das Lesen von der SSD nun wirklich geht: sudo dd if=/dev/sda of=/dev/zero bs=1M count=8192 status=progress ist ein probates Mittel (status=progress geht wahrscheinlich bei der 12.3 noch nicht) Seltsam, meiner Erfahrung nach müsste trotz SATA II, gerade wegen der 2GB RAM und dem daraus geringerem Disk-Cache, ein großer Unterschied bemerkbar sein. Oder aber war die Erwartungshaltung einfach zu groß ;) Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Am 16.01.2019 um 07:09 schrieb h.albert@odn.de: [ ... ]

muss den Rechner heute wieder an den Bestimmungsort bringen. Wenn ich's nicht vergesse setz ich mal den Befehl ab. Kann auch mal ein sudo hdparm -Tt /dev/sda hdparm -tT --direct /dev/sda machen, habe leider dann keinen Vergleich zur HDD, denn die ist zwar im Rechner, aber nicht angeschlossen und Zeit zum Aufschrauben ist nicht.

Keine Problem, bin halt jetzt nur neugierig ;) Bei meinem Befehl ist mir übrigens ein Fehler unterlaufen, soll natürlich /dev/null anstatt /dev/zero sein. Habe übrigens bei meinem 'Uralt' Backup-Server (das Board ist von 2006) mal den Test gefahren, ich erreiche da bei einer 120GB Samsung 840 an einem SATA II Port zwischen 207 und 226 MB/s. Bei üblichen Desktop HD's (5400 1/min) liegt der Wert so bei 110 MB/s, nur so als Vergleich. Bei deiner 160er dürfte es wahrscheinlich so knapp unter 100 sein. Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Am 16.01.2019 um 16:54 schrieb h.albert@odn.de:

Zitat von Manfred Kreisl :

...

Am 16.01.2019 um 07:09 schrieb h.albert@odn.de:

[ ... ]

...

muss den Rechner heute wieder an den Bestimmungsort bringen. Wenn ich's nicht vergesse setz ich mal den Befehl ab. Kann auch mal ein sudo hdparm -Tt /dev/sda hdparm -tT --direct /dev/sda machen, habe leider dann keinen Vergleich zur HDD, denn die ist zwar im Rechner, aber nicht angeschlossen und Zeit zum Aufschrauben ist nicht.

Keine Problem, bin halt jetzt nur neugierig ;)

# hdparm -Tt /dev/sda

/dev/sda: Timing cached reads: 694 MB in 2.01 seconds = 345.80 MB/sec Timing buffered disk reads: 382 MB in 3.00 seconds = 127.20 MB/sec

# hdparm -tT --direct /dev/sda

/dev/sda: Timing O_DIRECT cached reads: 246 MB in 2.01 seconds = 122.22 MB/sec Timing O_DIRECT disk reads: 386 MB in 3.00 seconds = 128.55 MB/sec

...

Bei meinem Befehl ist mir übrigens ein Fehler unterlaufen, soll natürlich /dev/null anstatt /dev/zero sein.

Habe übrigens bei meinem 'Uralt' Backup-Server (das Board ist von 2006) mal den Test gefahren, ich erreiche da bei einer 120GB Samsung 840 an einem SATA II Port zwischen 207 und 226 MB/s. Bei üblichen Desktop HD's (5400 1/min) liegt der Wert so bei 110 MB/s, nur so als Vergleich. Bei deiner 160er dürfte es wahrscheinlich so knapp unter 100 sein.

# dd if=/dev/sda of=/dev/null bs=1M count=8192 8192+0 records in 8192+0 records out 8589934592 bytes (8.6 GB) copied, 66.6018 s, 129 MB/s

ist nicht so toll, oder?

Nee, wirklich nicht. Da stimmt definitiv irgendetwas nicht.

Liegt es vielleicht an den Einträgen in /etc/fstab acl,user_xattr,noatime,nodiratime,discard? Nein, das nicht, da sowohl dd als auch hdparm am eigendlichen Dateisystem vorbei operiert

Ich vermute mal eher, dass die SSD nur im SATA I Mode läuft. Falls smartmontools installiert sind, starte mal sudo smartctl -a /dev/sda | grep "SATA Version" Da kommt aus Ausgabe so was wie kmnote5:/srv/scratch/vdr # smartctl -a /dev/sda | grep "SATA Version" SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s) Bei dir kommt dann vermutlich 'current: 1.5 Gb/s' Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Am 16.01.2019 um 19:37 schrieb Herbert Albert:

Am Mittwoch, 16. Januar 2019, 18:01:57 CET schrieb Manfred Kreisl:

...

Am 16.01.2019 um 16:54 schrieb h.albert@odn.de:

...

Zitat von Manfred Kreisl :

...

Am 16.01.2019 um 07:09 schrieb h.albert@odn.de:

[ ... ]

...

muss den Rechner heute wieder an den Bestimmungsort bringen. Wenn ich's nicht vergesse setz ich mal den Befehl ab. Kann auch mal ein sudo hdparm -Tt /dev/sda hdparm -tT --direct /dev/sda machen, habe leider dann keinen Vergleich zur HDD, denn die ist zwar im Rechner, aber nicht angeschlossen und Zeit zum Aufschrauben ist nicht.

Keine Problem, bin halt jetzt nur neugierig ;)

# hdparm -Tt /dev/sda

/dev/sda: Timing cached reads: 694 MB in 2.01 seconds = 345.80 MB/sec Timing buffered disk reads: 382 MB in 3.00 seconds = 127.20 MB/sec

# hdparm -tT --direct /dev/sda

/dev/sda: Timing O_DIRECT cached reads: 246 MB in 2.01 seconds = 122.22 MB/sec Timing O_DIRECT disk reads: 386 MB in 3.00 seconds = 128.55 MB/sec

...

Bei meinem Befehl ist mir übrigens ein Fehler unterlaufen, soll natürlich /dev/null anstatt /dev/zero sein.

Habe übrigens bei meinem 'Uralt' Backup-Server (das Board ist von 2006) mal den Test gefahren, ich erreiche da bei einer 120GB Samsung 840 an einem SATA II Port zwischen 207 und 226 MB/s. Bei üblichen Desktop HD's (5400 1/min) liegt der Wert so bei 110 MB/s, nur so als Vergleich. Bei deiner 160er dürfte es wahrscheinlich so knapp unter 100 sein.

# dd if=/dev/sda of=/dev/null bs=1M count=8192 8192+0 records in 8192+0 records out 8589934592 bytes (8.6 GB) copied, 66.6018 s, 129 MB/s

ist nicht so toll, oder?

Nee, wirklich nicht. Da stimmt definitiv irgendetwas nicht.

...

Liegt es vielleicht an den Einträgen in /etc/fstab acl,user_xattr,noatime,nodiratime,discard?

Nein, das nicht, da sowohl dd als auch hdparm am eigendlichen Dateisystem vorbei operiert

Ich vermute mal eher, dass die SSD nur im SATA I Mode läuft.

Falls smartmontools installiert sind, starte mal

sudo smartctl -a /dev/sda | grep "SATA Version"

Da kommt aus Ausgabe so was wie

kmnote5:/srv/scratch/vdr # smartctl -a /dev/sda | grep "SATA Version" SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)

Bei dir kommt dann vermutlich 'current: 1.5 Gb/s'

Manfred Hallo Manfred,

da komm ich jetzt schon schnell nicht wieder hin. Evtl. einmal, wenn ich mich per Fernwartung aufschlate. Angesteckt ist es am Board auf SATA2, ist lt. Handbuch 3.0Gb/s. Als Kabel habe ich ein SATA II Kabel (mit Clip) verwendet und im Bios kann man nichts einstellen.

War da nicht mal etwas mit hdparm sudo hdparm -i /dev/sda zeigt dann etwas wie UDMA modes und DMA modes.

Ja, ist aber in diesem Fall nicht aussagekräftig. Wenn kein (U)DMA Mode aktiv wäre, wäre das noch vieeeel langsamer. dmesg auch was an, das sieht dann in etwa wie folgt aus: dmesg | grep -i \ ata [1068912.164543] ata1.02: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 [1068912.171477] ata1.02: waking up from sleep [1068912.176441] ata1.02: hard resetting link [1068912.495796] ata1.02: SATA link up 1.5 Gbps (SStatus 113 SControl 320) [1068912.515966] ata1.02: configured for UDMA/133 [1068912.520944] ata1: EH complete [1079585.063028] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 [1079585.069845] ata1.00: waking up from sleep [1079585.074749] ata1.00: hard resetting link [1079585.390687] ata1.00: SATA link up 1.5 Gbps (SStatus 113 SControl 320) [1079585.400309] ata1.00: configured for UDMA/133 [1079585.409043] ata1: EH complete Die Ausgabe 'SATA link up 1.5 Gbps' deckt sich bei meinem Server in diesem Falle mit der Ausgabe von smartctl Auf diesem Homeserver (das ist ein Cubieboard2 mit ARM CPU und SATA Port Multiplier) verbinden sich die Disks auch nur über SATA I (warum nur SATA I weiß ich nicht genau, liegt wahrscheinlich am Port Multiplier, ist aber in diesem Falle auch nicht weiter tragisch) Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Am 17.01.2019 um 19:51 schrieb Herbert Albert:

Am Mittwoch, 16. Januar 2019, 19:58:03 CET schrieb Manfred Kreisl:

...

Am 16.01.2019 um 19:37 schrieb Herbert Albert:

...

Am Mittwoch, 16. Januar 2019, 18:01:57 CET schrieb Manfred Kreisl:

...

Am 16.01.2019 um 16:54 schrieb h.albert@odn.de:

...

Zitat von Manfred Kreisl :

...

Am 16.01.2019 um 07:09 schrieb h.albert@odn.de:

[ ... ]

> muss den Rechner heute wieder an den Bestimmungsort bringen. Wenn > ich's > nicht vergesse setz ich mal den Befehl ab. Kann auch mal ein > sudo hdparm -Tt /dev/sda > hdparm -tT --direct /dev/sda > machen, habe leider dann keinen Vergleich zur HDD, denn die ist zwar > im > Rechner, aber nicht angeschlossen und Zeit zum Aufschrauben ist nicht.

Keine Problem, bin halt jetzt nur neugierig ;)

# hdparm -Tt /dev/sda

/dev/sda: Timing cached reads: 694 MB in 2.01 seconds = 345.80 MB/sec Timing buffered disk reads: 382 MB in 3.00 seconds = 127.20 MB/sec

# hdparm -tT --direct /dev/sda

/dev/sda: Timing O_DIRECT cached reads: 246 MB in 2.01 seconds = 122.22 MB/sec Timing O_DIRECT disk reads: 386 MB in 3.00 seconds = 128.55 MB/sec

...

Bei meinem Befehl ist mir übrigens ein Fehler unterlaufen, soll natürlich /dev/null anstatt /dev/zero sein.

Habe übrigens bei meinem 'Uralt' Backup-Server (das Board ist von 2006) mal den Test gefahren, ich erreiche da bei einer 120GB Samsung 840 an einem SATA II Port zwischen 207 und 226 MB/s. Bei üblichen Desktop HD's (5400 1/min) liegt der Wert so bei 110 MB/s, nur so als Vergleich. Bei deiner 160er dürfte es wahrscheinlich so knapp unter 100 sein.

# dd if=/dev/sda of=/dev/null bs=1M count=8192 8192+0 records in 8192+0 records out 8589934592 bytes (8.6 GB) copied, 66.6018 s, 129 MB/s

ist nicht so toll, oder?

Nee, wirklich nicht. Da stimmt definitiv irgendetwas nicht.

...

Liegt es vielleicht an den Einträgen in /etc/fstab acl,user_xattr,noatime,nodiratime,discard?

Nein, das nicht, da sowohl dd als auch hdparm am eigendlichen Dateisystem vorbei operiert

Ich vermute mal eher, dass die SSD nur im SATA I Mode läuft.

Falls smartmontools installiert sind, starte mal

sudo smartctl -a /dev/sda | grep "SATA Version"

Da kommt aus Ausgabe so was wie

kmnote5:/srv/scratch/vdr # smartctl -a /dev/sda | grep "SATA Version" SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)

Bei dir kommt dann vermutlich 'current: 1.5 Gb/s'

Manfred

Hallo Manfred,

da komm ich jetzt schon schnell nicht wieder hin. Evtl. einmal, wenn ich mich per Fernwartung aufschlate. Angesteckt ist es am Board auf SATA2, ist lt. Handbuch 3.0Gb/s. Als Kabel habe ich ein SATA II Kabel (mit Clip) verwendet und im Bios kann man nichts einstellen.

War da nicht mal etwas mit hdparm sudo hdparm -i /dev/sda zeigt dann etwas wie UDMA modes und DMA modes.

Ja, ist aber in diesem Fall nicht aussagekräftig. Wenn kein (U)DMA Mode aktiv wäre, wäre das noch vieeeel langsamer.

dmesg auch was an, das sieht dann in etwa wie folgt aus:

dmesg | grep -i \ ata [1068912.164543] ata1.02: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 [1068912.171477] ata1.02: waking up from sleep [1068912.176441] ata1.02: hard resetting link [1068912.495796] ata1.02: SATA link up 1.5 Gbps (SStatus 113 SControl 320) [1068912.515966] ata1.02: configured for UDMA/133 [1068912.520944] ata1: EH complete [1079585.063028] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 [1079585.069845] ata1.00: waking up from sleep [1079585.074749] ata1.00: hard resetting link [1079585.390687] ata1.00: SATA link up 1.5 Gbps (SStatus 113 SControl 320) [1079585.400309] ata1.00: configured for UDMA/133 [1079585.409043] ata1: EH complete

Die Ausgabe 'SATA link up 1.5 Gbps' deckt sich bei meinem Server in diesem Falle mit der Ausgabe von smartctl

Auf diesem Homeserver (das ist ein Cubieboard2 mit ARM CPU und SATA Port Multiplier) verbinden sich die Disks auch nur über SATA I (warum nur SATA I weiß ich nicht genau, liegt wahrscheinlich am Port Multiplier, ist aber in diesem Falle auch nicht weiter tragisch)

Manfred Hallo Manfred,

ich konnte jetzt nochmals aus der Ferne auf den Rechner zugreifen und habe folgendes ausgegeben:

# dmesg | grep -i \ ata [ 0.968932] ata1: SATA max UDMA/133 cmd 0xe800 ctl 0xe480 bmdma 0xe000 irq 21 [ 0.968935] ata2: SATA max UDMA/133 cmd 0xe400 ctl 0xe080 bmdma 0xe008 irq 21 [ 0.969882] ata3: SATA max UDMA/133 cmd 0xdc00 ctl 0xd880 bmdma 0xd400 irq 20 [ 0.969885] ata4: SATA max UDMA/133 cmd 0xd800 ctl 0xd480 bmdma 0xd408 irq 20 [ 1.272031] ata3: SATA link down (SStatus 0 SControl 300) [ 1.272057] ata1: SATA link down (SStatus 0 SControl 300) [ 1.726048] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 1.726509] ata2.00: ATA-11: TOSHIBA-TR200, SBFA12.5, max UDMA/133 [ 1.726512] ata2.00: 468862128 sectors, multi 16: LBA48 NCQ (depth 31/32) [ 1.727634] ata2.00: configured for UDMA/133 [ 1.727751] scsi 1:0:0:0: Direct-Access ATA TOSHIBA-TR200 SBFA PQ: 0 ANSI: 5 [ 2.031035] ata4: SATA link down (SStatus 0 SControl 300) [ 2.079438] ata5: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xffa0 irq 14 [ 2.079441] ata6: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xffa8 irq 15 [ 2.249422] ata5.00: ATAPI: HL-DT-ST DVDRAM GSA-4163B, A101, max UDMA/33 [ 2.249430] ata5: nv_mode_filter: 0x739f&0x739f->0x739f, BIOS=0x7000 (0xc0000000) ACPI=0x701f (60:900:0x11) [ 2.271355] ata5.00: configured for UDMA/33

# smartctl -a /dev/sda | grep "SATA Version" SATA Version is: SATA >3.1, 6.0 Gb/s (current: 1.5 Gb/s)

hdparm -i /dev/sda

/dev/sda:

Model=TOSHIBA-TR200, FwRev=SBFA12.5, SerialNo=X8PB70LIK46S Config={ Fixed } RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=0 BuffType=unknown, BuffSize=unknown, MaxMultSect=16, MultSect=16 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=468862128 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120} PIO modes: pio0 pio3 pio4 DMA modes: mdma0 mdma1 mdma2 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6 AdvancedPM=no WriteCache=enabled Drive conforms to: Unspecified: ATA/ATAPI-3,4,5,6,7

* signifies the current active mode

Warum SATA auf 1.5Gb/s läuft weis ich nicht. Laut Handbuch und Kaufvertrag (den habe ich wirklich noch) steht da eindeutig SATA II.

Nun, jetzt könnte man sagen: wzbw (Pflegten meine Mathematik Lehrer/Profs stets zu sagen) :) Leider weiß ich da jetzt auch keinen Rat mehr [1]. Schon irgendwie enttäuschend Hatte gestern festgestellt, dass meine 2.5" im Notebook auch nur 3.0GBit connected (obwohl sie SATA III beherrscht), wohingegen die SSD im selben Gerät mit 6.0GBit läuft. Ist mir aber in diesem Fall egal, da eine 2.5" rotierende Disk eh dadurch nicht ausgebremst wird (wenn man mal von dem mickrigen Cache absieht), eine SSD hingegen natürlich schon. Manfred [1] Der Kernel sieht so etwas schon vor, dir Frage ist natürlich ob das auch so funktioniert. Ausprobiert habe ich es (noch) nicht. https://serverfault.com/questions/400338/how-to-reduce-the-sata-link-speed-o... -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Zitat von Hugo Egon Maurer :

Am 17.01.2019 um 19:51 schrieb Herbert Albert:

...

Warum SATA auf 1.5Gb/s läuft weis ich nicht. Laut Handbuch und Kaufvertrag (den habe ich wirklich noch) steht da eindeutig SATA II.

Herbert

Hallo,

ist im Bios AHCI eingeschalten?

Gruß

Hugo Egon Maurer

-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Hallo Hugo, der Rechner steht nicht mehr bei mir, also kann ich im Moment nicht im Bios nachsehen. Doch soweit ich das gesehen habe gab es da keinerlei Hinweis auf AHCI. Kannst auch gerne mal im Manual schmökern. https://dlcdnets.asus.com/pub/ASUS/mb/socket939/A8N-VMCSM/e2294_a8n-vm_csm.p... Gruß Herbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Am 19.01.2019 um 14:43 schrieb Herbert Albert: [ ... ]

was bewirkt eigentlich AHCI genau? wie ich gesehen habe ist auch bei meinem Rechner AHCI im Bios ausgeschaltet. Ich meine, dass vor 11 Jahren, als ich die Workstation mit einer damaligen SuSE in Betrieb genommen habe die Platten mit AHCI nicht gefunden wurden, ist aber schon zu lange her um es genau zu wissen. Ich müsste mich da auch erst wieder informieren, aber gewisse Features (NCQ beispielsweise) sind nicht verfügbar.

Was würde mit einem bestehenden System passieren, wenn ich nun im Bios AHCI probehalber einschalte? Datenverlust?

Gar nichts. Windows (zumindest war es mal so) würde ohne an der Registry herumzufummeln nicht mehr booten, aber Linux ist da flexibel. Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Am 19.01.2019 um 17:42 schrieb Herbert Albert:

Am Samstag, 19. Januar 2019, 15:03:28 CET schrieb Manfred Kreisl:

...

Am 19.01.2019 um 14:43 schrieb Herbert Albert: [ ... ]

...

was bewirkt eigentlich AHCI genau? wie ich gesehen habe ist auch bei meinem Rechner AHCI im Bios ausgeschaltet. Ich meine, dass vor 11 Jahren, als ich die Workstation mit einer damaligen SuSE in Betrieb genommen habe die Platten mit AHCI nicht gefunden wurden, ist aber schon zu lange her um es genau zu wissen. Ich müsste mich da auch erst wieder informieren, aber gewisse Features (NCQ beispielsweise) sind nicht verfügbar.

...

Was würde mit einem bestehenden System passieren, wenn ich nun im Bios AHCI probehalber einschalte? Datenverlust?

Gar nichts. Windows (zumindest war es mal so) würde ohne an der Registry herumzufummeln nicht mehr booten, aber Linux ist da flexibel.

Manfred stimmt, nur das die Plattenreihenfolge im Bios durcheinander gewürfelt wird. /dev/sdc wird nun zu /dev/sdg.

Die Werte sind aber auch nicht übermäßig gestiegen (alte Werte gerade nicht verfügbar)

~ # dd if=/dev/sdg of=/dev/null bs=1M count=8192 8192+0 records in 8192+0 records out 8589934592 bytes (8.6 GB, 8.0 GiB) copied, 63.0968 s, 136 MB/s

~ # hdparm -tT --direct /dev/sdg

/dev/sdg: Timing O_DIRECT cached reads: 514 MB in 2.00 seconds = 256.70 MB/sec Timing O_DIRECT disk reads: 456 MB in 3.01 seconds = 151.61 MB/sec

~ # hdparm -tT /dev/sdg

/dev/sdg: Timing cached reads: 4494 MB in 2.00 seconds = 2250.87 MB/sec Timing buffered disk reads: 430 MB in 3.01 seconds = 142.90 MB/sec

Herbert

Wurde ja auch nicht behauptet. Zumindest auf Desktop-Systemen bringt das praktisch so gut wie nichts (spürbares). Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Am 14.01.19 um 21:10 schrieb Herbert Albert: ..

Wie hast Du deine SSD in die fstab eingetragen, so wie bei Sebastian Siebert beschrieben? Mit: acl,user_xattr,noatime,nodiratime,discard

da findest Du verschiedene Meinungen, u.a nach https://wiki.archlinux.de/title/Noatime genügt: acl,user_xattr,noatime, Ich verwende es auch bei swap. Peter -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Am 14.01.19 um 23:48 schrieb Manfred Kreisl:

Am 14.01.2019 um 22:34 schrieb Peter McD:

...

... genügt:

acl,user_xattr,noatime, Schaden tut nodiratime aber auch nicht

...

Ich verwende es auch bei swap.

Da hingegen ist es nutzlos

Wahrscheinlich hast du recht, aber hast du auch eine Quelle dafür? Ich finde für Ubuntu nur einen Hinweis, dass "beim Start automatisch "discard" für swap ausgeführt wird. Peter -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Am 15.01.19 um 14:34 schrieb Manfred Kreisl:

Am 15.01.2019 um 11:56 schrieb Peter McD:

...

Am 14.01.19 um 23:48 schrieb Manfred Kreisl:

...

Am 14.01.2019 um 22:34 schrieb Peter McD:

...

...

... genügt:

acl,user_xattr,noatime, Schaden tut nodiratime aber auch nicht

...

Ich verwende es auch bei swap.

Da hingegen ist es nutzlos

Wahrscheinlich hast du recht, aber hast du auch eine Quelle dafür? Ich finde für Ubuntu nur einen Hinweis, dass "beim Start automatisch "discard" für swap ausgeführt wird.

Wahrscheinlich liegt hier ein Missverständnis vor. Ich bezog das 'nutzlos' auf acl,user_xattr,noatime für Swap, wohingegen Du wahrscheinlich discard meintest. Das ist natürlich auch für Swap relevant. Hierfür ist 'man swapon' recht nützlich, interessant hierbei ist der Satz 'This may improve performance on some Solid  State  Devices,  but often it does not', welcher natürlich nicht gerade hilfreich ist :)

Manfred

-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Am Sonntag, 13. Januar 2019, 18:00:58 CET schrieb Herbert Albert:

Am Sonntag, 13. Januar 2019, 15:20:27 CET schrieb Manfred Kreisl:

...

Am 13.01.2019 um 15:01 schrieb Bernhard Junk:

...

Hallo Zusammen und ein frohes neues Jahr.

...

Das stimmt nur bedingt: Das stimmt gar nicht !!!

...

Ich ahbe ein älteres ASUS-Board ( 2005 ) mit Sata II. Daran habe ich eine SSD von Kingston mit 250GB angeschlossen. Läuft super! Bernd

Klar, warum auch nicht. Habe selber so eine Konfiguration

Manfred

Hallo Manfred,

die SATA-SSD wird in den Desktop ja nur an das SATA-Kabel angeschlossen. Für was ist eigentlich der Steckfuß daneben?

Herbert Habe gerade beim Googlen gesehen, dass wohl 3.5" SSD auch einen Stromanschluss haben, die OCZ TR200 ist eine 2.5", da meinte der schlaue Verkäufer, die brauchen keinen. Kann es sein, dass die älteren Mainboards die SSD nicht mit Strom versorgen?

-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Am Sonntag, 13. Januar 2019, 18:18:30 CET schrieb Manfred Kreisl:

Am 13.01.2019 um 18:13 schrieb Herbert Albert:

...

Am Sonntag, 13. Januar 2019, 18:00:58 CET schrieb Herbert Albert:

...

Am Sonntag, 13. Januar 2019, 15:20:27 CET schrieb Manfred Kreisl:

...

Am 13.01.2019 um 15:01 schrieb Bernhard Junk:

...

Hallo Zusammen und ein frohes neues Jahr.

...

Das stimmt nur bedingt: Das stimmt gar nicht !!!

...

Ich ahbe ein älteres ASUS-Board ( 2005 ) mit Sata II. Daran habe ich eine SSD von Kingston mit 250GB angeschlossen. Läuft super! Bernd

Klar, warum auch nicht. Habe selber so eine Konfiguration

Manfred

Hallo Manfred,

die SATA-SSD wird in den Desktop ja nur an das SATA-Kabel angeschlossen. Für was ist eigentlich der Steckfuß daneben?

Herbert

Habe gerade beim Googlen gesehen, dass wohl 3.5" SSD auch einen Stromanschluss haben, die OCZ TR200 ist eine 2.5", da meinte der schlaue Verkäufer, die brauchen keinen. Kann es sein, dass die älteren Mainboards die SSD nicht mit Strom versorgen?

3.5" SSD's - gibt's das?

Nein, wie gesagt, beide Stecker müssen angeschlossen werden, egal ob 2.5" oder 3.5". Der einzige Unterschied ist, dass eine 3.5" HD +12V/+5V benötigt, eine SSD hingegen nur +5V. Beides geht aber über den breiten Stecker

Manfred dann hat mir der freundliche Verkäufer mit viel Ahnung einen Schmarren erzählt. Der meinte die SSD braucht keinen separaten Stromanschluss, die bekommt ihre Versorgungsspannung über das Datenkabel. Externe 2.5" Paltten würden auch so funktionieren. Ist aber wohl ein Unterschied, ob vom USB-Port oder vom SATA-Daten-Port.

Herbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Am 13.01.19 um 18:13 schrieb Herbert Albert:

Habe gerade beim Googlen gesehen, dass wohl 3.5" SSD auch einen Stromanschluss haben, die OCZ TR200 ist eine 2.5", da meinte der schlaue Verkäufer, die brauchen keinen. Kann es sein, dass die älteren Mainboards die SSD nicht mit Strom versorgen?

Welcher "schlaue Verkäufer" hat dir den diesen Bären aufgebunden??? Keine Festplatte oder SSD läuft bisher ohne Stromversorgung! Je nach Anschlussvariante kann es sein, dass kein separater Stromanschlussstecker an der HDD/SSD benötigt wird und dies über das (separate) Kabel am gemeinsamen Daten-/Strom-Stecker läuft (z. B. bei SAS HDDs oder in Notebooks). Die Anschlüsse bei normalem SATA haben ja andere hier schon beschrieben. Hier gibt es beispielsweise auch Adapterkabel mit Molex-Stecker (5+12V) und SATA-Stromversorgungsanschluss für die HDD/SSD. Bei externen USB-Festplatten wird heute die Stromversorgung über ein einziges USB-Anschlusskabel realisiert. Intern sind es letztlich auch zwei Stecker. Früher waren das auch extern zwei USB-Kabel, die man anschließen musste. Auch ich habe diversen Uralt-PC's mit einer SSD ein neues schnelleres Leben gegönnt. Da gab es nie Probleme! Bei Museums-PC's half dann wenigstens ein SATA-Controller. HTH -- VG Mathias -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Am 13.01.2019 um 15:19 schrieb Manfred Kreisl:

Am 13.01.2019 um 11:29 schrieb H.-Stefan Neumeyer:

...

Am Sonntag, den 13.01.2019, 10:48 +0100 schrieb Herbert Albert:

Hallo Herbert

...

Im aktuellen Fall habe ich einen betagten Desktop-PC (Ende 2007) mit Mainboard ASUS A8N-VM T-System CSM und SATA II. An den wollte ich eine Toshiba

^^^^^^^^^^^^^^^^

...

Das Board sollte mindesten SATA III bereitstellen können. Drunter geht nichts, und wenn doch - bringt es schlicht nichts. Denn dann ist die Schnittstelle der engste Flaschenhals. Das ist völliger Blödsinn. Du hast wohl noch nicht kapiert, in welchen Bereichen eine SSD den größten Geschwindigkeits-Gewinn (zumindest an SATA Ports) bringt. Nämlich die Eliminierung der Seek Zeiten und Latenz, und da bringt eine SSD auch noch an einem SATA I Port eine Menge

Ich habe übrigens auch so ein Uraltboard (ich denke das ist noch älter als Alberts), da werkelt seit Jahren eine Samsung 840 dran an dem Onboard SATA II, kein Problem.

...

Irgendwo habe ich einen Artikel dazu, finde den aber auf die Schnelle nicht. Den wirst Du auch nicht finden, den gibt es nämlich nicht, der existiert nur in deiner Einbildung!

@Albert Sorry, meinte natürlich Herbert Ist schon etwas verwirrend, wenn man einen Nachnamen hat, der auch ein Vorname sein könnte.

-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Am 13.01.2019 um 17:58 schrieb Herbert Albert:

Am Sonntag, 13. Januar 2019, 15:42:14 CET schrieb Manfred Kreisl:

...

Am 13.01.2019 um 15:19 schrieb Manfred Kreisl:

...

Am 13.01.2019 um 11:29 schrieb H.-Stefan Neumeyer:

...

Am Sonntag, den 13.01.2019, 10:48 +0100 schrieb Herbert Albert:

Hallo Herbert

...

Im aktuellen Fall habe ich einen betagten Desktop-PC (Ende 2007) mit Mainboard ASUS A8N-VM T-System CSM und SATA II. An den wollte ich eine Toshiba

^^^^^^^^^^^^^^^^

Das Board sollte mindesten SATA III bereitstellen können. Drunter geht nichts, und wenn doch - bringt es schlicht nichts. Denn dann ist die Schnittstelle der engste Flaschenhals.

Das ist völliger Blödsinn. Du hast wohl noch nicht kapiert, in welchen Bereichen eine SSD den größten Geschwindigkeits-Gewinn (zumindest an SATA Ports) bringt. Nämlich die Eliminierung der Seek Zeiten und Latenz, und da bringt eine SSD auch noch an einem SATA I Port eine Menge

Ich habe übrigens auch so ein Uraltboard (ich denke das ist noch älter als Alberts), da werkelt seit Jahren eine Samsung 840 dran an dem Onboard SATA II, kein Problem.

...

Irgendwo habe ich einen Artikel dazu, finde den aber auf die Schnelle nicht.

Den wirst Du auch nicht finden, den gibt es nämlich nicht, der existiert nur in deiner Einbildung!

@Albert

Sorry, meinte natürlich Herbert Ist schon etwas verwirrend, wenn man einen Nachnamen hat, der auch ein Vorname sein könnte. Hallo Manfred,

schon gut, passiert mir öfters. Kann ich mir vorstellen :)

zu dem eigentlichen Problem: Du meinst, dass meine beiden Boards die Toshiba OCZ TR200 SSD vielleicht nicht mögen. Die werde ich dann wohl versuchen bei dem großen Elektro-Riesen wieder an den netten Verkäufer zu bringen. Der wollte mir eigentlich eine M.2 andrehen, da deutlich schnelle, doch als ich ihn gesagt habe, dass sie in einen ca. 10 Jahre alten Rechner soll, hat er zu der OCZ TR200 gegriffen.

Gibt es denn eine Empfehlung welche SATA-SSD (ca. 250GB) zuverlässig mit älteren Boards lufen könnte?

Keine Ahnung, aber wie gesagt, im Grunde genommen sollten ALLE funktionieren. Aber ich denke, mit Samsung kannst Du nichts verkehrt machen, wobei ich selbst bislang keine Samsung gekauft habe (die 840er war eine Geschenk von meinem Sohn) Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Am Sonntag, den 13.01.2019, 16:10 +0100 schrieb Robert Großkopf: Hallo Robert Laß gut sein.

So einen Ton bin ich in dieser Mailingliste nicht gewohnt. Soll ja in manchen Foren üblich sein, aber doch nicht auch noch hier.

Der Jugendfreund Kreisl hat halt die Linux-Weißheiten mit dem Löffel gefressen. Der Klügere gibt nach. Die von mir erwähnter, angeblich nicht existierende Ausarbeitung entstammt dem Begleitmaterial für eine Weiterbildung, wurde verfaßt von einem Informatiker an der Uni Hamburg, und beschäftigt sich auf 2x ca. 20 Seiten sowohl mit den technischen Grundlage (Aufbau, Arbeitsweise), als auch dem praktischen täglichen Einsatz von SSD. Der mir beim posten nicht mehr im Wortlaut erinnerliche Passus, auf den ich mich mit der Anmerkung zum "Flaschenhals" bezogen habe: ---------------------------------------------------------------------- SATA III (SATA 600) kann mit bis zu 6 Gbit/s Daten übertragen. SATA II (SATA 300) dagegen nur mit der Hälfte (3 Gbit/s). Bei 270 MByte/s ist bei einem SATA-II-Controller die technisch mögliche Grenze erreicht. In der Praxis liegt bei solchen alten Controllern die Übertragungsrate noch deutlich darunter. ---------------------------------------------------------------------- Ist aber nicht mehr relevant, denn ich bin nun auch hier unwiederuflich weg -- Gruß Stefan Mein seit dem 17.10.2018 auf diesem Rechner benutztes Betriebssystem ist: Debian GNU/Linux Sid "unstable"