Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.os.unix.linux.misc > #130968

Re: Soft-RAID: MDADM vs. LVM2

Show all headers | View raw

Marcel Mueller <news.5.maazl@spamgourmet.org> schrieb:

> Am 29.05.23 um 19:29 schrieb Marcus Jodorf:
>> Seit AHCI bei SATA Standard ist, ist auch hotplug Standard. Also seit
>> ungefähr ewig.
>
> Das stimmt so nicht.

Doch, das stimmt so.

> Es ist optional. Auch die Platten (oder SSDs)
> müssen das können.

Du wirfst hier Protokoll und physikalischen/elektrischen Anschluß
durcheinander.

Natürlich kannst Du nicht einfach hotplug mit Standardkabeln machen.

Aber mit geeignetem elektrischen Anschluß - sprich passenden Steckern,
wie Du sie bei ensprechend geeigneten Backplanes und Einschüben findest,
die die Steckverbindung in der richtigen elektrischen Reihenfolge
sicherstellen, ist das kein Problem.

Dann kann das jedes AHCI SATA Gerät und jeder übliche AHCI SATA on-board
Anschluß - wenn der Treiber auch noch mitspielt.

Also mit geeignetem Wechselrahmen funktioniert das mit jeder AHCI Platte
an jedem Board. Die Linuxtreiber unterstützen das selbstverständlich.

> Das Problem ist nicht das SATA-Kabel, sondern das Anstecken der
> Stromversorgung. Da wird ein entladener Kondensator schlagartig an die
> Stromversorgung des Rechners angeschlossen. Das ist faktisch ein
> kurzzeitiger Kurzschluss. Das führt zum einen zu einem sehr hohen
> Strom, üblicherweise über den Maximum Ratings des Kondensators. Das
> überlebt der meistens, aber eben nicht immer - dann ist die Platte
> hin. Zum anderen bricht die Spannung im PC dadurch kurzzeitig ein. Da
> der i.A. der Stärkere ist, ist der Einbruch eher gering. Aber die
> steilflankige Störung kann schon Komponenten zum Absturz bringen. Ich
> kenne Fälle, wo das zu einem Reboot führte.

Wenn Du das mit ungeeigneten Steckverbindungen machst, klar - da ist das
nicht vorgesehen. Mit geeigneten Steckverbindungen für Hotplug aber
überhaupt kein Problem. Alles schon praktisch mit Platten aller
Hersteller endlos oft gemacht. Völlig stabil und zuverlässig.

> Hotplug-fähige Devices habe eine geeignete Strombegrenzung für diesen
> Vorgang eingebaut.

Nein. Da müssen eigentlich nur die Steckkontakte in der richtigen,
elektrisch sicheren Reihenfolge geschlossen werden. Also Masseverbindung
zuerst verbunden und zuletzt getrennt. Mir ist noch kein Gerät begegnet,
daß das dann nicht kann.
Wenn Du Dir mal die SATA Verbindung der Stromversorgung anschaust,
siehst Du nebenbei, daß das auch der Standardstecker versucht, mit
längeren Massepins sicherzustellen. Deshalb kann das sogar damit
funktionieren. Natürlich viel sicherer und besser mit wirklich dafür
ausgelegten Anschlüssen.

> Und auch da muss man eigentlich geeignete Platten einbauen.
> Zumindest die Billigdinger haben keinen DC/DC Wandler eingebaut, der
> die Spannung der Platte beim verriegeln langsam (in Millisekunden)
> hochfährt. Damit könnte man beliebige Devices einbauen.

Mir ist in 15 Jahren noch keine einzige Platte begegnet, die da jemals
ein Problem mit gehabt oder unzuverlässig funktioniert hätte.
(Ich habe hier im Moment 23 Platten aller Hersteller und Altersklassen
und schon viele Dutzend weitere als Hotswap verwendet und das tut
solide.)

Hotplug ist im Standard vorgesehen. Eine Laufwerk, das das nicht kann,
ist nicht standardkonform. Ich kann mir da eigentlich nicht
vorstellen, daß Hersteller da inkompatible Hardware bauen.
Nebenbei gab es in den Anfangsjahren von AHCI auch mal eSATA. Da wurden
auch mal dafür passende Steckverbindungen definiert.
War nur extrem unpraktisch weil Daten und Stromversorgung getrennt und
Windows hat da so seine Problemchen mit dem Handling der Treiber gehabt.
Entsprechend ist eSATA ganz schnell wieder vom Markt verschwunden.

>> Dir sind einfach bisher offenbar zu wenig Platten verstorben.
>
> Vielleicht. Ich kaufe halt auch nicht jeden Müll, für Heimserver
> üblicherweise Entry-Server-Klasse. Natürlich kann trotzdem mal was
> verrecken. Dreimal hatte ich das auch schon, aber in 30 Jahren. Zwei
> der drei Fälle waren zudem mir zugelaufene IBM ICL35..., das
> Server-Pendant zu den Deathstars.

Ich kaufe auch fast nur Enterprise. Die Ausfallraten hängen aber
vornehmlich an der Menge der verwendeten Platten und auch daran, wann
man kauft. In den letzten Jahren sind Platten z.B. auffällig
zuverlässiger geworden. Oder ich habe eine Glückssträhne ;-)
Vor 20 Jahren sind die im Vergleich dagegen deutlich häufiger quer über
alle Modelle und Hersteller verreckt.

Rein privat sind mir bisher so ungefähr in den letzten 25 Jahren alleine
23 oder 24 Platten verstorben. In den letzten ungefähr 7 Jahren
dankenswerterweise zur Abwechslung aber mal keine mehr.
Ich habe aber auch immer wenigstens 10 Platten im Dauerbetrieb. Und
früher entsprechend immer 5 oder 6 SCSI Platten im privaten Rechner.
Wenn man viele Platten verwendet, dann sterben auch viele. ;-)

>> Größeres Backup wieder einzuspielen, kann schlicht ewig dauern.
>
> Naja, wenn nur eine Platte/SSD hin ist, muss man auch nur eine
> wiederherstellen. Das dauert hier vielleicht zwei bis vier
> Stunden. Für privat ist das OK.

Solange Du nur kleine Platten hast. Auch wenn moderne Platten relativ
schnell sind, kannst Du da bei aktuellen Plattengrößen auch gerne mal
länger als 24h drauf warten bis die komplett zurückgespielt ist.
Das dauernd einfach selbst bei maximalem Tempo so lange.
Die Schreibraten haben mit den Kapazitäten nicht Schritt gehalten.

> Bei SSDs ist das Tempo doch komplett egal. Die sind eh schneller als
> man braucht.

Kommt darauf an ;-)
Meine SSDs machen so 7/5 GB/s lesen/schreiben. Ich bündel sie dennoch zu
gespiegelten Pärchen. Natürlich vornehmlich wegen Redundanz und die 14
GB/s in der Spitze und etwas mehr IOPS nehme ich dann auch noch mit.

> Ich bin immer wieder überrascht, wie viele Leute riesige Dateien
> duplizieren. Außer Backup fällt mir kein Grund ein, warum ich so etwas
> tun sollte. Und Backups, die 700MB/s schaffen sind eher selten.

Mein Backup vom PC zum Homeserver läuft mit annähernd 1GB/s.

Von SSDs im PC als Quelle und dann auf Raid im Homeserver kommt man halt
entsprechend auf Tempo.

Die hohe Schreibleistung ist auch dann ein Segen, wenn man z.B. wie ich
öfter mal große VM Images hin und herschiebt (weil irgendwann bekommt man
nicht mehr genug SSDs in normale Rechner und muß dann auslagern, was
gerade nicht benötigt wird).

>> Klar, dann kannst Du das teilweise nicht nachvollziehen. Wenn ein
>> Restore aus Backup bei Dir mal Tage dauert, reden wir da vielleicht
>> nochmal drüber.
>
> Dann wird es Zeit aufzuräumen. ;-)
> Oder das Backupverfahren ist ungeeignet, denn alles, was mehr als
> einige Stunden dauert, wirft über kurz oder lang auch organisatorische
> Probleme auf.

Natürlich. Aber so oder so stößt man in Sachen Restore von Backup
relativ schnell an Grenzen. Rein physikalisch durch die Datenmenge, die
man noch durch die Leitung bzw. Schnittstelle bekommt und pro
Zeiteinheit lesen/schreiben kann.
Aktuelle Platten brauchen halt wie gesagt zum Beispiel durchaus mal
länger als einen vollen Tag, um einmal ihren kompletten Inhalt schreiben
oder lesen zu können.


Gruß,

Marcus
⚂⚃

Back to de.comp.os.unix.linux.misc | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Soft-RAID: MDADM vs. LVM2 Friedemann Stoyan <usenet@ip6-mail.de> - 2023-05-28 05:47 +0200
  Re: Soft-RAID: MDADM vs. LVM2 Marcel Mueller <news.5.maazl@spamgourmet.org> - 2023-05-28 08:28 +0200
    Re: Soft-RAID: MDADM vs. LVM2 Friedemann Stoyan <usenet@ip6-mail.de> - 2023-05-28 09:37 +0200
      Re: Soft-RAID: MDADM vs. LVM2 Marcel Mueller <news.5.maazl@spamgourmet.org> - 2023-05-28 11:14 +0200
        Re: Soft-RAID: MDADM vs. LVM2 Marco Moock <mo01@posteo.de> - 2023-05-28 11:35 +0200
          Re: Soft-RAID: MDADM vs. LVM2 Marcel Mueller <news.5.maazl@spamgourmet.org> - 2023-05-28 12:20 +0200
            Re: Soft-RAID: MDADM vs. LVM2 Arno Welzel <usenet@arnowelzel.de> - 2023-06-12 09:43 +0200
        Re: Soft-RAID: MDADM vs. LVM2 Marcus Jodorf <m@bogomips.de> - 2023-05-29 19:29 +0200
          Re: Soft-RAID: MDADM vs. LVM2 Marco Moock <mo01@posteo.de> - 2023-05-29 20:53 +0200
            Re: Soft-RAID: MDADM vs. LVM2 Tim Ritberg <tim@server.invalid> - 2023-05-29 20:56 +0200
              Re: Soft-RAID: MDADM vs. LVM2 Marco Moock <mo01@posteo.de> - 2023-05-29 21:47 +0200
                Re: Soft-RAID: MDADM vs. LVM2 Tim Ritberg <tim@server.invalid> - 2023-05-29 22:21 +0200
                Re: Soft-RAID: MDADM vs. LVM2 Marco Moock <mo01@posteo.de> - 2023-05-30 08:29 +0200
                Re: Soft-RAID: MDADM vs. LVM2 Marcus Jodorf <m@bogomips.de> - 2023-05-30 18:58 +0200
                Re: Soft-RAID: MDADM vs. LVM2 Marco Moock <mo01@posteo.de> - 2023-05-30 22:17 +0200
                Re: Soft-RAID: MDADM vs. LVM2 Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2023-05-31 09:05 +0200
                Re: Soft-RAID: MDADM vs. LVM2 Alexander Schreiber <als@usenet.thangorodrim.de> - 2023-05-31 17:07 +0200
            Re: Soft-RAID: MDADM vs. LVM2 Arno Welzel <usenet@arnowelzel.de> - 2023-06-12 09:46 +0200
          Re: Soft-RAID: MDADM vs. LVM2 Marcel Mueller <news.5.maazl@spamgourmet.org> - 2023-05-30 07:39 +0200
            Re: Soft-RAID: MDADM vs. LVM2 Marco Moock <mo01@posteo.de> - 2023-05-30 08:30 +0200
              Re: Soft-RAID: MDADM vs. LVM2 Marcel Mueller <news.5.maazl@spamgourmet.org> - 2023-05-31 22:10 +0200
            Re: Soft-RAID: MDADM vs. LVM2 Marcus Jodorf <m@bogomips.de> - 2023-05-30 20:06 +0200
              Re: Soft-RAID: MDADM vs. LVM2 SimplyNews <Simply.News@gmx.de> - 2023-05-30 21:34 +0200
                Re: Soft-RAID: MDADM vs. LVM2 Marcus Jodorf <m@bogomips.de> - 2023-05-31 18:47 +0200
              Re: Soft-RAID: MDADM vs. LVM2 Marcel Mueller <news.5.maazl@spamgourmet.org> - 2023-05-31 21:34 +0200
          Re: Soft-RAID: MDADM vs. LVM2 Arno Welzel <usenet@arnowelzel.de> - 2023-06-12 09:46 +0200
        Re: Soft-RAID: MDADM vs. LVM2 Arno Welzel <usenet@arnowelzel.de> - 2023-06-12 09:42 +0200
  Re: Soft-RAID: MDADM vs. LVM2 Stefan Möding <May2023.5.kill-9@spamgourmet.com> - 2023-05-28 10:07 +0200
  Re: Soft-RAID: MDADM vs. LVM2 Tim Ritberg <tim@server.invalid> - 2023-05-28 10:57 +0200
    Re: Soft-RAID: MDADM vs. LVM2 Friedemann Stoyan <usenet@ip6-mail.de> - 2023-05-29 11:16 +0200
      Re: Soft-RAID: MDADM vs. LVM2 Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2023-05-29 09:23 +0000
        Re: Soft-RAID: MDADM vs. LVM2 Friedemann Stoyan <usenet@ip6-mail.de> - 2023-05-29 11:26 +0200
          Re: Soft-RAID: MDADM vs. LVM2 Tim Ritberg <tim@server.invalid> - 2023-05-29 12:31 +0200
      Re: Soft-RAID: MDADM vs. LVM2 Tim Ritberg <tim@server.invalid> - 2023-05-29 11:30 +0200
        Re: Soft-RAID: MDADM vs. LVM2 Friedemann Stoyan <usenet@ip6-mail.de> - 2023-05-29 11:37 +0200
          Re: Soft-RAID: MDADM vs. LVM2 Marcus Jodorf <m@bogomips.de> - 2023-05-29 19:37 +0200
            Re: Soft-RAID: MDADM vs. LVM2 "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-05-29 21:57 +0200
        Re: Soft-RAID: MDADM vs. LVM2 "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-05-29 12:17 +0200
  Re: Soft-RAID: MDADM vs. LVM2 Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2023-05-28 11:07 +0000
    Re: Soft-RAID: MDADM vs. LVM2 Friedemann Stoyan <usenet@ip6-mail.de> - 2023-05-29 11:25 +0200
      Re: Soft-RAID: MDADM vs. LVM2 Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2023-05-29 12:35 +0000
        Re: Soft-RAID: MDADM vs. LVM2 Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2023-05-29 16:43 +0200
          Re: Soft-RAID: MDADM vs. LVM2 Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2023-05-29 17:20 +0000
            Re: Soft-RAID: MDADM vs. LVM2 Marcus Jodorf <m@bogomips.de> - 2023-05-29 19:44 +0200
            Re: Soft-RAID: MDADM vs. LVM2 Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2023-05-30 08:52 +0200
              Re: Soft-RAID: MDADM vs. LVM2 Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2023-05-30 07:06 +0000
            Re: Soft-RAID: MDADM vs. LVM2 Alexander Schreiber <als@usenet.thangorodrim.de> - 2023-05-31 17:04 +0200
      Re: Soft-RAID: MDADM vs. LVM2 Friedemann Stoyan <usenet@ip6-mail.de> - 2023-06-02 10:34 +0200

csiph-web