Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
smbd --foreground --no-process-group
1 view
Skip to first unread message
Kay Martinen
Jan 27, 2024, 2:00:03 PM1/27/24
to
Hallo
Ich teste grade ein Mainboard das evtl. einen Ersatz-Fileserver
darstellen soll mit einem Debian 12 64-Bit und einem KDE Desktop drauf.
Und einem aktuellem Webmin 2 als Fern-Verwaltung.
CPU ist ein Phenom II X4, 16GB RAM und eine 60 GB SSD als Bootplatte.
Dazu 2* 2TB und 2* 4TB einzelne HDDs (kein RAID o. JBOD) auf denen
Videodaten liegen. Das Board (GA-790-XTA-UD4) hat ca. 8 Interne S-ATA
Ports und eSATA.
Jetzt sind mir div. kleine aussetzer aufgefallen und ich frage mich ob
es daran liegt wie der smbd dort (wohl vom systemd) gestartet wird.
In der prozessliste sehe ich den mit den optionen
smbd --foreground --no-process-group
Und ich frage mich ob die mit systemd, dem Desktop oder mit etwas
anderem zu tun haben könnten.
Sollte ein Samba nicht als daemon im Hintergrund laufen? Wozu dann der
-foreground Parameter?
Für das Streamen von Videos an eine Kodi-Instanz auf einem Laptop oder
Raspi 3b+ ist das alles schnell genug, allerdings habe ich neulich bei
größeren Datentransfers enttäuschend niedrige Durchsatz-zahlen gesehen.
Ich meine die Platten und das GbE LAN interface sollten mehr schaffen
können aber ich hab da auch noch keinerlei optimierungen versucht.
Via GbE per LAN zu dem Host waren es m.E. nie mehr als 30-40MB/s und von
einer Externen 2,5" USB Platte (transfer von ca. 300 GB) waren es
anfangs kaum mehr als 10 MB/s die später AFAIR auf ca. 30MB/s stiegen.
Letzteres ging als Ziel auf eine 2 TB S-ATA Platte.
Aussetzer waren z.b. ein Kodi auf dem Laptop der einen Ordner in einer
Freigabe öffnen wollte, was ihm aber nicht gelang. Der Stand erst still
und mußte dann beendet werden. Zeitgleich vom gleichen host aus war der
ssh auf dem Zielhost nicht erreichbar, ping warf auch unavailable aus
und auf dem Ziel hatte sich der Desktop verabschiedet - aber offenbar
erst bei mausbewegung. Vom Raspi aus auf das gleiche ziel hat es den
auch zum stehen gebracht (für minuten).
Ein 'systemctl stop user.slice' auf dem Ziel/Server hat den
login-manager zurückgebraucht, erneutes einloggen ging.
Ein Zweiter versuch sowohl vom Laptop als auch vom raspi aus
funktionierte dann.
Der Samba startet aber dennoch beim systemstart und nicht etwa; wie man
denken könnte oder ich befürchtete; erst nach einer user-anmeldung. Es
dauert offenbar nur etwas bis der nach dem Start auch wirklich läuft.
Ｂｙｅ／
／Ｋａｙ
--
"Kann ein Wurstbrot die Welt retten?" :-)
Ich teste grade ein Mainboard das evtl. einen Ersatz-Fileserver
darstellen soll mit einem Debian 12 64-Bit und einem KDE Desktop drauf.
Und einem aktuellem Webmin 2 als Fern-Verwaltung.
CPU ist ein Phenom II X4, 16GB RAM und eine 60 GB SSD als Bootplatte.
Dazu 2* 2TB und 2* 4TB einzelne HDDs (kein RAID o. JBOD) auf denen
Videodaten liegen. Das Board (GA-790-XTA-UD4) hat ca. 8 Interne S-ATA
Ports und eSATA.
Jetzt sind mir div. kleine aussetzer aufgefallen und ich frage mich ob
es daran liegt wie der smbd dort (wohl vom systemd) gestartet wird.
In der prozessliste sehe ich den mit den optionen
smbd --foreground --no-process-group
Und ich frage mich ob die mit systemd, dem Desktop oder mit etwas
anderem zu tun haben könnten.
Sollte ein Samba nicht als daemon im Hintergrund laufen? Wozu dann der
-foreground Parameter?
Für das Streamen von Videos an eine Kodi-Instanz auf einem Laptop oder
Raspi 3b+ ist das alles schnell genug, allerdings habe ich neulich bei
größeren Datentransfers enttäuschend niedrige Durchsatz-zahlen gesehen.
Ich meine die Platten und das GbE LAN interface sollten mehr schaffen
können aber ich hab da auch noch keinerlei optimierungen versucht.
Via GbE per LAN zu dem Host waren es m.E. nie mehr als 30-40MB/s und von
einer Externen 2,5" USB Platte (transfer von ca. 300 GB) waren es
anfangs kaum mehr als 10 MB/s die später AFAIR auf ca. 30MB/s stiegen.
Letzteres ging als Ziel auf eine 2 TB S-ATA Platte.
Aussetzer waren z.b. ein Kodi auf dem Laptop der einen Ordner in einer
Freigabe öffnen wollte, was ihm aber nicht gelang. Der Stand erst still
und mußte dann beendet werden. Zeitgleich vom gleichen host aus war der
ssh auf dem Zielhost nicht erreichbar, ping warf auch unavailable aus
und auf dem Ziel hatte sich der Desktop verabschiedet - aber offenbar
erst bei mausbewegung. Vom Raspi aus auf das gleiche ziel hat es den
auch zum stehen gebracht (für minuten).
Ein 'systemctl stop user.slice' auf dem Ziel/Server hat den
login-manager zurückgebraucht, erneutes einloggen ging.
Ein Zweiter versuch sowohl vom Laptop als auch vom raspi aus
funktionierte dann.
Der Samba startet aber dennoch beim systemstart und nicht etwa; wie man
denken könnte oder ich befürchtete; erst nach einer user-anmeldung. Es
dauert offenbar nur etwas bis der nach dem Start auch wirklich läuft.
Ｂｙｅ／
／Ｋａｙ
--
"Kann ein Wurstbrot die Welt retten?" :-)
Marcel Mueller
Jan 28, 2024, 5:06:40 AM1/28/24
to
Am 27.01.24 um 19:56 schrieb Kay Martinen:
> Und einem aktuellem Webmin 2 als Fern-Verwaltung.
>
> CPU ist ein Phenom II X4, 16GB RAM und eine 60 GB SSD als Bootplatte.
Und der dürfte die Stromrechnung auch ganz gut polieren, wenn nicht
gerade Eine Solaranlage mit Speicher installiert ist.
> Dazu 2* 2TB und 2* 4TB einzelne HDDs (kein RAID o. JBOD) auf denen
> Videodaten liegen. Das Board (GA-790-XTA-UD4) hat ca. 8 Interne S-ATA
> Ports und eSATA.
Das sollte eine Weile reichen.
> Jetzt sind mir div. kleine aussetzer aufgefallen und ich frage mich ob
> es daran liegt wie der smbd dort (wohl vom systemd) gestartet wird.
? -v
Was verstehst du unter Aussetzer.
> In der prozessliste sehe ich den mit den optionen
>
> smbd --foreground --no-process-group
>
> Und ich frage mich ob die mit systemd, dem Desktop oder mit etwas
> anderem zu tun haben könnten.
Naja, eine systemd-Unit wird das schon sein. Allerdings startet Samba
AFAIk für jede aktive Connection einen weiteren Prozess.
> Sollte ein Samba nicht als daemon im Hintergrund laufen? Wozu dann der
> -foreground Parameter?
Denke mal, dass systemd auf die Tour die Messages für systemctl status
abfischt.
> Für das Streamen von Videos an eine Kodi-Instanz auf einem Laptop oder
> Raspi 3b+ ist das alles schnell genug, allerdings habe ich neulich bei
> größeren Datentransfers enttäuschend niedrige Durchsatz-zahlen gesehen.
> Ich meine die Platten und das GbE LAN interface sollten mehr schaffen
> können aber ich hab da auch noch keinerlei optimierungen versucht.
Gbit LAN packt, wenn alles gut läuft 100MB/s. Die meisten Platten packen
das aber nur unter Idealbedingungen. Es dürfen halt wirklich nahezu
keine Kopfbewegungen dabei sein, sonst bricht die Rate dramatisch ein.
> Via GbE per LAN zu dem Host waren es m.E. nie mehr als 30-40MB/s und von
> einer Externen 2,5" USB Platte (transfer von ca. 300 GB) waren es
> anfangs kaum mehr als 10 MB/s die später AFAIR auf ca. 30MB/s stiegen.
> Letzteres ging als Ziel auf eine 2 TB S-ATA Platte.
Die Zielplatte ist aber nicht zufällig ein SMR-Exemplar?
Und die Daten mussten hoffentlich nicht zweimal übers Netz, oder? (also
für Quelle und Ziel)
> Aussetzer waren z.b. ein Kodi auf dem Laptop der einen Ordner in einer
> Freigabe öffnen wollte, was ihm aber nicht gelang. Der Stand erst still
> und mußte dann beendet werden.
Das hört sich aber eher danach an, das da etwas mit der Verbindung nicht
stimmt.
> Zeitgleich vom gleichen host aus war der
> ssh auf dem Zielhost nicht erreichbar, ping warf auch unavailable aus
> und auf dem Ziel hatte sich der Desktop verabschiedet - aber offenbar
> erst bei mausbewegung.
Ich würde sagen, die Kiste (oder eine Platte) hat einen klatsch.
Guck mal im syslog, ob da was hinweisgebendes drin steht. So
SATA-Timeouts wären z.B. heiße Kandidaten, ggf. kombiniert mit
Lesefehlern einer Platte - die dauern meist ewig, wegen Retry.
> Ein Zweiter versuch sowohl vom Laptop als auch vom raspi aus
> funktionierte dann.
Wie gesagt, logs checken. Ein Hardwareproblem ist nicht unwahrscheinlich.
Ein Problem mit Samba an sich, halte ich bei den Symptomen für
unwahrscheinlich.
> Der Samba startet aber dennoch beim systemstart und nicht etwa; wie man
> denken könnte oder ich befürchtete; erst nach einer user-anmeldung. Es
> dauert offenbar nur etwas bis der nach dem Start auch wirklich läuft.
Ja, das dürfte normal sein. Aber wie gesagt, samba nutzt normalerweise
pro Sitzung eigene Daemon-Instanzen.
Marcel
> Ich teste grade ein Mainboard das evtl. einen Ersatz-Fileserver
> darstellen soll mit einem Debian 12 64-Bit und einem KDE Desktop drauf.
KDE ist auch das erste, woran ich bei einem Fileserver zuerst denke. :-)
> darstellen soll mit einem Debian 12 64-Bit und einem KDE Desktop drauf.
> Und einem aktuellem Webmin 2 als Fern-Verwaltung.
>
> CPU ist ein Phenom II X4, 16GB RAM und eine 60 GB SSD als Bootplatte.
gerade Eine Solaranlage mit Speicher installiert ist.
> Dazu 2* 2TB und 2* 4TB einzelne HDDs (kein RAID o. JBOD) auf denen
> Videodaten liegen. Das Board (GA-790-XTA-UD4) hat ca. 8 Interne S-ATA
> Ports und eSATA.
> Jetzt sind mir div. kleine aussetzer aufgefallen und ich frage mich ob
> es daran liegt wie der smbd dort (wohl vom systemd) gestartet wird.
Was verstehst du unter Aussetzer.
> In der prozessliste sehe ich den mit den optionen
>
> smbd --foreground --no-process-group
>
> Und ich frage mich ob die mit systemd, dem Desktop oder mit etwas
> anderem zu tun haben könnten.
AFAIk für jede aktive Connection einen weiteren Prozess.
> Sollte ein Samba nicht als daemon im Hintergrund laufen? Wozu dann der
> -foreground Parameter?
abfischt.
> Für das Streamen von Videos an eine Kodi-Instanz auf einem Laptop oder
> Raspi 3b+ ist das alles schnell genug, allerdings habe ich neulich bei
> größeren Datentransfers enttäuschend niedrige Durchsatz-zahlen gesehen.
> Ich meine die Platten und das GbE LAN interface sollten mehr schaffen
> können aber ich hab da auch noch keinerlei optimierungen versucht.
das aber nur unter Idealbedingungen. Es dürfen halt wirklich nahezu
keine Kopfbewegungen dabei sein, sonst bricht die Rate dramatisch ein.
> Via GbE per LAN zu dem Host waren es m.E. nie mehr als 30-40MB/s und von
> einer Externen 2,5" USB Platte (transfer von ca. 300 GB) waren es
> anfangs kaum mehr als 10 MB/s die später AFAIR auf ca. 30MB/s stiegen.
> Letzteres ging als Ziel auf eine 2 TB S-ATA Platte.
Und die Daten mussten hoffentlich nicht zweimal übers Netz, oder? (also
für Quelle und Ziel)
> Aussetzer waren z.b. ein Kodi auf dem Laptop der einen Ordner in einer
> Freigabe öffnen wollte, was ihm aber nicht gelang. Der Stand erst still
> und mußte dann beendet werden.
stimmt.
> Zeitgleich vom gleichen host aus war der
> ssh auf dem Zielhost nicht erreichbar, ping warf auch unavailable aus
> und auf dem Ziel hatte sich der Desktop verabschiedet - aber offenbar
> erst bei mausbewegung.
Guck mal im syslog, ob da was hinweisgebendes drin steht. So
SATA-Timeouts wären z.B. heiße Kandidaten, ggf. kombiniert mit
Lesefehlern einer Platte - die dauern meist ewig, wegen Retry.
> Ein Zweiter versuch sowohl vom Laptop als auch vom raspi aus
> funktionierte dann.
Ein Problem mit Samba an sich, halte ich bei den Symptomen für
unwahrscheinlich.
> Der Samba startet aber dennoch beim systemstart und nicht etwa; wie man
> denken könnte oder ich befürchtete; erst nach einer user-anmeldung. Es
> dauert offenbar nur etwas bis der nach dem Start auch wirklich läuft.
pro Sitzung eigene Daemon-Instanzen.
Marcel
Gerald E¡scher
Jan 29, 2024, 4:39:14 AM1/29/24
to
Marcel Mueller schrieb am 28/1/2024 11:06:
> Am 27.01.24 um 19:56 schrieb Kay Martinen:
>> Ich teste grade ein Mainboard das evtl. einen Ersatz-Fileserver
>> darstellen soll mit einem Debian 12 64-Bit und einem KDE Desktop drauf.
>
> KDE ist auch das erste, woran ich bei einem Fileserver zuerst denke. :-)
*prust*
> Am 27.01.24 um 19:56 schrieb Kay Martinen:
>> Ich teste grade ein Mainboard das evtl. einen Ersatz-Fileserver
>> darstellen soll mit einem Debian 12 64-Bit und einem KDE Desktop drauf.
>
> KDE ist auch das erste, woran ich bei einem Fileserver zuerst denke. :-)
>> Und einem aktuellem Webmin 2 als Fern-Verwaltung.
>>
>> CPU ist ein Phenom II X4, 16GB RAM und eine 60 GB SSD als Bootplatte.
>
> Und der dürfte die Stromrechnung auch ganz gut polieren, wenn nicht
> gerade Eine Solaranlage mit Speicher installiert ist.
4-Kernern, die jeweils auf 3 Kernen Proteine falten. Reicht, mir ist
nicht kalt :-)
--
Gerald
Kay Martinen
Jan 29, 2024, 2:40:03 PM1/29/24
to
Am 29.01.24 um 10:39 schrieb Gerald E¡scher:
>>> darstellen soll mit einem Debian 12 64-Bit und einem KDE Desktop drauf.
>>
>> KDE ist auch das erste, woran ich bei einem Fileserver zuerst denke. :-)
>
> *prust*
Was würdet ihr denn als OS für einen Test eines Boards benutzen?
FreeNAS, OMV oder irgendwas ähnliches das evtl. mit eigenen Automatiken
versuchte Fehlern entgegen zu steuern?
Die Aufgabe ist prinzipiell simpel gestrickt. Vier oder mehr Platten
sollen als ganzes oder mit eigenen Freigaben per SMB und ggf. NFS über
1-2 LAN Ports frei gegeben werden.
Optional und Nice2have wäre automatischer suspend nach Zeit und WoL bei
bedarf (nicht eben Server-typisch oder).
Und da wahrscheinlich noch "Luft" bleibt wäre ein weiteres nice2have
dort via Virtualbox ein paar VMs mit Alten OS laufen zu lassen. Die
idealerweise beim suspend angehalten werden und beim Aufwachen wieder
gestartet werden. Wobei AltOS eher OS/2 sein soll. Oder Win9x u.ä.
Linux, DOS und andere Windows können auch auf ProxMox laufen, bei obigen
ist VB m.E. besser geeignet. Schon wg. des RDP-Supports.
Und, ist der Desktop dann immer noch nutzlos?
Es ist wie gesagt ein Test. Nicht schnell und Schmutzig sondern etwas
längerfristig gedacht mit Optionen für div. Ausbauten. Die man in den
oft eingeschränkten Paketauswahlen von $Server_system nicht unbedingt
findet.
Man muß den Desktop später ja nicht starten lassen.
Bei Windows Server ist das IMO eh nicht anders vorgesehen, nur bei einer
Hypervisor-Only Kostenlos Version soll es keinen Desktop geben...
Das soll jetzt kein Pro-Windows Statement sein!
> Marcel Mueller schrieb am 28/1/2024 11:06:
>
>> Am 27.01.24 um 19:56 schrieb Kay Martinen:
>>> Ich teste grade ein Mainboard das evtl. einen Ersatz-Fileserver
^^^^^ !!!
>
>> Am 27.01.24 um 19:56 schrieb Kay Martinen:
>>> Ich teste grade ein Mainboard das evtl. einen Ersatz-Fileserver
>>> darstellen soll mit einem Debian 12 64-Bit und einem KDE Desktop drauf.
>>
>> KDE ist auch das erste, woran ich bei einem Fileserver zuerst denke. :-)
>
> *prust*
FreeNAS, OMV oder irgendwas ähnliches das evtl. mit eigenen Automatiken
versuchte Fehlern entgegen zu steuern?
Die Aufgabe ist prinzipiell simpel gestrickt. Vier oder mehr Platten
sollen als ganzes oder mit eigenen Freigaben per SMB und ggf. NFS über
1-2 LAN Ports frei gegeben werden.
Optional und Nice2have wäre automatischer suspend nach Zeit und WoL bei
bedarf (nicht eben Server-typisch oder).
Und da wahrscheinlich noch "Luft" bleibt wäre ein weiteres nice2have
dort via Virtualbox ein paar VMs mit Alten OS laufen zu lassen. Die
idealerweise beim suspend angehalten werden und beim Aufwachen wieder
gestartet werden. Wobei AltOS eher OS/2 sein soll. Oder Win9x u.ä.
Linux, DOS und andere Windows können auch auf ProxMox laufen, bei obigen
ist VB m.E. besser geeignet. Schon wg. des RDP-Supports.
Und, ist der Desktop dann immer noch nutzlos?
Es ist wie gesagt ein Test. Nicht schnell und Schmutzig sondern etwas
längerfristig gedacht mit Optionen für div. Ausbauten. Die man in den
oft eingeschränkten Paketauswahlen von $Server_system nicht unbedingt
findet.
Man muß den Desktop später ja nicht starten lassen.
Bei Windows Server ist das IMO eh nicht anders vorgesehen, nur bei einer
Hypervisor-Only Kostenlos Version soll es keinen Desktop geben...
Das soll jetzt kein Pro-Windows Statement sein!
Gerald E¡scher
Jan 30, 2024, 11:36:48 AM1/30/24
to
Kay Martinen schrieb am 29/1/2024 20:31:
> Am 29.01.24 um 10:39 schrieb Gerald E¡scher:
>> Marcel Mueller schrieb am 28/1/2024 11:06:
>>
>>> Am 27.01.24 um 19:56 schrieb Kay Martinen:
>>>> Ich teste grade ein Mainboard das evtl. einen Ersatz-Fileserver
> ^^^^^ !!!
>
>>>> darstellen soll mit einem Debian 12 64-Bit und einem KDE Desktop drauf.
>>>
>>> KDE ist auch das erste, woran ich bei einem Fileserver zuerst denke. :-)
>>
>> *prust*
>
> Was würdet ihr denn als OS für einen Test eines Boards benutzen?
Knoppix oder UBCD. Um festzustellen, ob das Board funktioniert, braucht
> Am 29.01.24 um 10:39 schrieb Gerald E¡scher:
>> Marcel Mueller schrieb am 28/1/2024 11:06:
>>
>>> Am 27.01.24 um 19:56 schrieb Kay Martinen:
>>>> Ich teste grade ein Mainboard das evtl. einen Ersatz-Fileserver
> ^^^^^ !!!
>
>>>> darstellen soll mit einem Debian 12 64-Bit und einem KDE Desktop drauf.
>>>
>>> KDE ist auch das erste, woran ich bei einem Fileserver zuerst denke. :-)
>>
>> *prust*
>
> Was würdet ihr denn als OS für einen Test eines Boards benutzen?
es keine Betriebssysteminstallation, außer dir ist ziemlich langweilig.
> Linux, DOS und andere Windows können auch auf ProxMox laufen, bei obigen
> ist VB m.E. besser geeignet. Schon wg. des RDP-Supports.
>
> Und, ist der Desktop dann immer noch nutzlos?
--
Gerald
Kay Martinen
Jan 30, 2024, 12:20:02 PM1/30/24
to
Am 30.01.24 um 17:36 schrieb Gerald E¡scher:
warten bis die Live-CD sich durchgewuselt hat finde ich maximal
unbequem. Und Virtualbox möchte ich auch nicht via CLI steuern.
Das ist ein Privates Projekt, da gibt es keinen Druck in x Stunden alles
durch getestet zu haben.
> Kay Martinen schrieb am 29/1/2024 20:31:
>
>> Am 29.01.24 um 10:39 schrieb Gerald E¡scher:
>>> Marcel Mueller schrieb am 28/1/2024 11:06:
>>>
>>>> Am 27.01.24 um 19:56 schrieb Kay Martinen:
>>>>> Ich teste grade ein Mainboard das evtl. einen Ersatz-Fileserver
>> ^^^^^ !!!
>>
>>>>> darstellen soll mit einem Debian 12 64-Bit und einem KDE Desktop drauf.
>
>> Am 29.01.24 um 10:39 schrieb Gerald E¡scher:
>>> Marcel Mueller schrieb am 28/1/2024 11:06:
>>>
>>>> Am 27.01.24 um 19:56 schrieb Kay Martinen:
>>>>> Ich teste grade ein Mainboard das evtl. einen Ersatz-Fileserver
>> ^^^^^ !!!
>>
>>>>> darstellen soll mit einem Debian 12 64-Bit und einem KDE Desktop drauf.
>> Was würdet ihr denn als OS für einen Test eines Boards benutzen?
>
> Knoppix oder UBCD. Um festzustellen, ob das Board funktioniert, braucht
> es keine Betriebssysteminstallation, außer dir ist ziemlich langweilig.
>
> Knoppix oder UBCD. Um festzustellen, ob das Board funktioniert, braucht
> es keine Betriebssysteminstallation, außer dir ist ziemlich langweilig.
>> Und, ist der Desktop dann immer noch nutzlos?
>
> Ja.
Dann ist mir halt Langweilig, und ich mag es bequem. Bei jedem Boot zu
>
> Ja.
warten bis die Live-CD sich durchgewuselt hat finde ich maximal
unbequem. Und Virtualbox möchte ich auch nicht via CLI steuern.
Das ist ein Privates Projekt, da gibt es keinen Druck in x Stunden alles
durch getestet zu haben.
Kay Martinen
Jan 31, 2024, 10:20:03 AM1/31/24
to
Am 28.01.24 um 11:06 schrieb Marcel Mueller:
nichts extra. Nur die Platten.
>> Jetzt sind mir div. kleine aussetzer aufgefallen und ich frage mich ob
>> es daran liegt wie der smbd dort (wohl vom systemd) gestartet wird.
>
> ? -v
>
> Was verstehst du unter Aussetzer.
Siehe unten.
>> smbd --foreground --no-process-group
>>
>> Und ich frage mich ob die mit systemd, dem Desktop oder mit etwas
>> anderem zu tun haben könnten.
>
> Naja, eine systemd-Unit wird das schon sein. Allerdings startet Samba
> AFAIk für jede aktive Connection einen weiteren Prozess.
> Und die Daten mussten hoffentlich nicht zweimal übers Netz, oder? (also
> für Quelle und Ziel)
Nein. Bei dem obigem NICHT-LAN Szenario mußten die via USB rein und via
internem S-ATA zur Platte raus.
>> Aussetzer waren z.b. ein Kodi auf dem Laptop der einen Ordner in einer
>> Freigabe öffnen wollte, was ihm aber nicht gelang. Der Stand erst still
>> und mußte dann beendet werden.
>
> Das hört sich aber eher danach an, das da etwas mit der Verbindung nicht
> stimmt.
>
>> Zeitgleich vom gleichen host aus war der
>> ssh auf dem Zielhost nicht erreichbar, ping warf auch unavailable aus
>> und auf dem Ziel hatte sich der Desktop verabschiedet - aber offenbar
>> erst bei mausbewegung.
>
> Ich würde sagen, die Kiste (oder eine Platte) hat einen klatsch.
> Guck mal im syslog, ob da was hinweisgebendes drin steht. So
> SATA-Timeouts wären z.B. heiße Kandidaten, ggf. kombiniert mit
> Lesefehlern einer Platte - die dauern meist ewig, wegen Retry.
Da muß ich heute noch mal suchen.
>> Ein Zweiter versuch sowohl vom Laptop als auch vom raspi aus
>> funktionierte dann.
>
> Wie gesagt, logs checken. Ein Hardwareproblem ist nicht unwahrscheinlich.
> Ein Problem mit Samba an sich, halte ich bei den Symptomen für
> unwahrscheinlich.
von mehreren Gigabyte ZU diesem Host da irgendwas blockiert und dann
einen <timeout-zeitspanne> langen komplett-ausfall der LAN Anbindung
verursacht. Ich hab schon die Netzkonfig untersucht, mit gufw die
Firewall-settings kontrolliert und alles auf erlaubten gesetzt.
Wie reagiert eigentlich ein systemd wenn z.b. der Samba abstirbt? Kann
es sein das der dann gleich ein ganzes bündel von units (an einem
LAN-Target?) stoppt und neu startet.
Bei den bisherigen Transfer-versuchen hat ein anschließendes ping auf
die IP generell über 100 bis ca. 150 versuche gemacht bis dann wieder
ein Echo zurück kam.
Und ssh oder samba sind in der zeit ja auch nicht erreichbar. Der
Versuch liefert nur "no route to host"
Jetzt werde ich erst mal in den logs nach krümeln des letzten heutigen
Fehlversuchs fahnden.
Es scheint mir möglich das ein Debian mit KDE evtl. doch keine so gute
Wahl war - aber in jedem Fall die Bequemere zum suchen und testen. Weil
der hier teils offen, auf Seite und mit echter K,V, M auf dem Tisch liegt.
Falls aber ein samba-fehler via systemd zu einem kompletten DoS führt
dann hätte das gleiche auch mit einem OMV-NAS o.ä. passieren können.
Denn der steckt da ebenfalls drin.
> Am 27.01.24 um 19:56 schrieb Kay Martinen:
>> Ich teste grade ein Mainboard das evtl. einen Ersatz-Fileserver
>> darstellen soll mit einem Debian 12 64-Bit und einem KDE Desktop drauf.
>> Ich teste grade ein Mainboard das evtl. einen Ersatz-Fileserver
>> darstellen soll mit einem Debian 12 64-Bit und einem KDE Desktop drauf.
>> Und einem aktuellem Webmin 2 als Fern-Verwaltung.
>> Dazu 2* 2TB und 2* 4TB einzelne HDDs (kein RAID o. JBOD) auf denen
>> Videodaten liegen. Das Board (GA-790-XTA-UD4) hat ca. 8 Interne S-ATA
>> Ports und eSATA.
>
> Das sollte eine Weile reichen.
War auch mein Gedanke. Und das Board hatte ich schon, es kostete mich
>> Videodaten liegen. Das Board (GA-790-XTA-UD4) hat ca. 8 Interne S-ATA
>> Ports und eSATA.
>
> Das sollte eine Weile reichen.
nichts extra. Nur die Platten.
>> Jetzt sind mir div. kleine aussetzer aufgefallen und ich frage mich ob
>> es daran liegt wie der smbd dort (wohl vom systemd) gestartet wird.
>
> ? -v
>
> Was verstehst du unter Aussetzer.
>> smbd --foreground --no-process-group
>>
>> Und ich frage mich ob die mit systemd, dem Desktop oder mit etwas
>> anderem zu tun haben könnten.
>
> Naja, eine systemd-Unit wird das schon sein. Allerdings startet Samba
> AFAIk für jede aktive Connection einen weiteren Prozess.
> Denke mal, dass systemd auf die Tour die Messages für systemctl status
> abfischt.
>
>> Für das Streamen von Videos an eine Kodi-Instanz auf einem Laptop oder
>> Raspi 3b+ ist das alles schnell genug, allerdings habe ich neulich bei
>> größeren Datentransfers enttäuschend niedrige Durchsatz-zahlen gesehen.
> abfischt.
>
>> Für das Streamen von Videos an eine Kodi-Instanz auf einem Laptop oder
>> Raspi 3b+ ist das alles schnell genug, allerdings habe ich neulich bei
>> größeren Datentransfers enttäuschend niedrige Durchsatz-zahlen gesehen.
>> Via GbE per LAN zu dem Host waren es m.E. nie mehr als 30-40MB/s und von
>> einer Externen 2,5" USB Platte (transfer von ca. 300 GB) waren es
>> anfangs kaum mehr als 10 MB/s die später AFAIR auf ca. 30MB/s stiegen.
>> Letzteres ging als Ziel auf eine 2 TB S-ATA Platte.
>
> Die Zielplatte ist aber nicht zufällig ein SMR-Exemplar?
Das ist möglich, ja. Allerdings wäre die hier weitgehend leer.
>> einer Externen 2,5" USB Platte (transfer von ca. 300 GB) waren es
>> anfangs kaum mehr als 10 MB/s die später AFAIR auf ca. 30MB/s stiegen.
>> Letzteres ging als Ziel auf eine 2 TB S-ATA Platte.
>
> Die Zielplatte ist aber nicht zufällig ein SMR-Exemplar?
> Und die Daten mussten hoffentlich nicht zweimal übers Netz, oder? (also
> für Quelle und Ziel)
internem S-ATA zur Platte raus.
>> Aussetzer waren z.b. ein Kodi auf dem Laptop der einen Ordner in einer
>> Freigabe öffnen wollte, was ihm aber nicht gelang. Der Stand erst still
>> und mußte dann beendet werden.
>
> Das hört sich aber eher danach an, das da etwas mit der Verbindung nicht
> stimmt.
>
>> Zeitgleich vom gleichen host aus war der
>> ssh auf dem Zielhost nicht erreichbar, ping warf auch unavailable aus
>> und auf dem Ziel hatte sich der Desktop verabschiedet - aber offenbar
>> erst bei mausbewegung.
>
> Ich würde sagen, die Kiste (oder eine Platte) hat einen klatsch.
> Guck mal im syslog, ob da was hinweisgebendes drin steht. So
> SATA-Timeouts wären z.B. heiße Kandidaten, ggf. kombiniert mit
> Lesefehlern einer Platte - die dauern meist ewig, wegen Retry.
>> Ein Zweiter versuch sowohl vom Laptop als auch vom raspi aus
>> funktionierte dann.
>
> Wie gesagt, logs checken. Ein Hardwareproblem ist nicht unwahrscheinlich.
> Ein Problem mit Samba an sich, halte ich bei den Symptomen für
> unwahrscheinlich.
> Ja, das dürfte normal sein. Aber wie gesagt, samba nutzt normalerweise
> pro Sitzung eigene Daemon-Instanzen.
Ich habe hier aktuell eher den Eindruck das bei einem Transfer via LAN
> pro Sitzung eigene Daemon-Instanzen.
von mehreren Gigabyte ZU diesem Host da irgendwas blockiert und dann
einen <timeout-zeitspanne> langen komplett-ausfall der LAN Anbindung
verursacht. Ich hab schon die Netzkonfig untersucht, mit gufw die
Firewall-settings kontrolliert und alles auf erlaubten gesetzt.
Wie reagiert eigentlich ein systemd wenn z.b. der Samba abstirbt? Kann
es sein das der dann gleich ein ganzes bündel von units (an einem
LAN-Target?) stoppt und neu startet.
Bei den bisherigen Transfer-versuchen hat ein anschließendes ping auf
die IP generell über 100 bis ca. 150 versuche gemacht bis dann wieder
ein Echo zurück kam.
Und ssh oder samba sind in der zeit ja auch nicht erreichbar. Der
Versuch liefert nur "no route to host"
Jetzt werde ich erst mal in den logs nach krümeln des letzten heutigen
Fehlversuchs fahnden.
Es scheint mir möglich das ein Debian mit KDE evtl. doch keine so gute
Wahl war - aber in jedem Fall die Bequemere zum suchen und testen. Weil
der hier teils offen, auf Seite und mit echter K,V, M auf dem Tisch liegt.
Falls aber ein samba-fehler via systemd zu einem kompletten DoS führt
dann hätte das gleiche auch mit einem OMV-NAS o.ä. passieren können.
Denn der steckt da ebenfalls drin.
Marcel Mueller
Jan 31, 2024, 12:55:46 PM1/31/24
to
Am 31.01.24 um 16:12 schrieb Kay Martinen:
müssen oft ein Vielfaches der übertragenen Datenmenge schreiben und sind
dadurch um den entsprechenden Faktor langsamer. Genaueres hängt
natürlich vom jeweiligen Anwendungsszenario ab. Aber selbst wenn man
größere Blöcke am Stück schreibt, müssen für das Schreiben der Metadaten
schnell mal 8MB geschrieben werden anstatt 4kb. Das macht es nicht
wirklich schnell.
> Ich habe hier aktuell eher den Eindruck das bei einem Transfer via LAN
> von mehreren Gigabyte ZU diesem Host da irgendwas blockiert und dann
> einen <timeout-zeitspanne> langen komplett-ausfall der LAN Anbindung
> verursacht.
Da kämen Packet-Loss - gibt aber nur einige Sekunden Pause - oder eben
auch SATA Timeouts in Frage. Letztere können locker eine halbe Minute
blockieren. Gefühlt würde ich auf letzteres tippen. Entweder matschige
SATA-Verbindungen oder defekte Sektoren auf den Platten.
> Wie reagiert eigentlich ein systemd wenn z.b. der Samba abstirbt? Kann
> es sein das der dann gleich ein ganzes bündel von units (an einem
> LAN-Target?) stoppt und neu startet.
Was zur Hölle ist ein LAN Target?
Wenn der Samba Daemon stirbt sind alle Verbindungen und Sessions weg.
Die Clients müssen sich dann neu Authentifizieren. Das geht
üblicherweise automatisch.
> Bei den bisherigen Transfer-versuchen hat ein anschließendes ping auf
> die IP generell über 100 bis ca. 150 versuche gemacht bis dann wieder
> ein Echo zurück kam.
Das _kann_ auf ein Netzwerk-Problem hindeuten. Es kann aber auch sein,
dass der Rechner so blockiert ist, dass er selbst auf Ping nicht mehr
antworten kann. Hänger auf dem Root-Volume können schon fast alles lahm
legen.
> Und ssh oder samba sind in der zeit ja auch nicht erreichbar. Der
> Versuch liefert nur "no route to host"
Dann ist sogar ARP verreckt. Kurzum, der IP-Adresse kann gar keine
MAC-Adresse mehr zugeordnet werden. Hast du irgendeinen, der ARP kaputt
machen will, z.B. über Spoofing? Zwei Rechner mit derselben IP wären
auch so ein Klassiker. Die schnappen sich gegenseitig immer die MAC weg.
Der ARP-Cache hält aber nicht sehr lange. Insofern kann das schon die
Folge von Verbindungsproblemen sein.
Ein kaputter NIC käme durchaus auch in Frage.
> Falls aber ein samba-fehler via systemd zu einem kompletten DoS führt
> dann hätte das gleiche auch mit einem OMV-NAS o.ä. passieren können.
> Denn der steckt da ebenfalls drin.
Nein, der würde sofort neu starten, jedenfalls ein paar mal. Das dauert
allenfalls Sekunden.
Marcel
>> Die Zielplatte ist aber nicht zufällig ein SMR-Exemplar?
>
> Das ist möglich, ja. Allerdings wäre die hier weitgehend leer.
Das ist egal. SMR-Platten haben eine übelste Write-Amplification. Die
>
> Das ist möglich, ja. Allerdings wäre die hier weitgehend leer.
müssen oft ein Vielfaches der übertragenen Datenmenge schreiben und sind
dadurch um den entsprechenden Faktor langsamer. Genaueres hängt
natürlich vom jeweiligen Anwendungsszenario ab. Aber selbst wenn man
größere Blöcke am Stück schreibt, müssen für das Schreiben der Metadaten
schnell mal 8MB geschrieben werden anstatt 4kb. Das macht es nicht
wirklich schnell.
> Ich habe hier aktuell eher den Eindruck das bei einem Transfer via LAN
> von mehreren Gigabyte ZU diesem Host da irgendwas blockiert und dann
> einen <timeout-zeitspanne> langen komplett-ausfall der LAN Anbindung
> verursacht.
auch SATA Timeouts in Frage. Letztere können locker eine halbe Minute
blockieren. Gefühlt würde ich auf letzteres tippen. Entweder matschige
SATA-Verbindungen oder defekte Sektoren auf den Platten.
> Wie reagiert eigentlich ein systemd wenn z.b. der Samba abstirbt? Kann
> es sein das der dann gleich ein ganzes bündel von units (an einem
> LAN-Target?) stoppt und neu startet.
Wenn der Samba Daemon stirbt sind alle Verbindungen und Sessions weg.
Die Clients müssen sich dann neu Authentifizieren. Das geht
üblicherweise automatisch.
> Bei den bisherigen Transfer-versuchen hat ein anschließendes ping auf
> die IP generell über 100 bis ca. 150 versuche gemacht bis dann wieder
> ein Echo zurück kam.
dass der Rechner so blockiert ist, dass er selbst auf Ping nicht mehr
antworten kann. Hänger auf dem Root-Volume können schon fast alles lahm
legen.
> Und ssh oder samba sind in der zeit ja auch nicht erreichbar. Der
> Versuch liefert nur "no route to host"
MAC-Adresse mehr zugeordnet werden. Hast du irgendeinen, der ARP kaputt
machen will, z.B. über Spoofing? Zwei Rechner mit derselben IP wären
auch so ein Klassiker. Die schnappen sich gegenseitig immer die MAC weg.
Der ARP-Cache hält aber nicht sehr lange. Insofern kann das schon die
Folge von Verbindungsproblemen sein.
Ein kaputter NIC käme durchaus auch in Frage.
> Falls aber ein samba-fehler via systemd zu einem kompletten DoS führt
> dann hätte das gleiche auch mit einem OMV-NAS o.ä. passieren können.
> Denn der steckt da ebenfalls drin.
allenfalls Sekunden.
Marcel
Kay Martinen
Jan 31, 2024, 2:30:03 PM1/31/24
to
Am 31.01.24 um 18:55 schrieb Marcel Mueller:
hinzugefügt würde. Das geht doch m.E. nicht über den Bus.
> natürlich vom jeweiligen Anwendungsszenario ab. Aber selbst wenn man
> größere Blöcke am Stück schreibt, müssen für das Schreiben der Metadaten
> schnell mal 8MB geschrieben werden anstatt 4kb.
Also quasi halb so schnell wie nicht-SMR Platten erwartbar.
Die vier Platten hier sind:
sdb: Hitachi HUA722020ALA331 2 TB Keine Angabe ob SMR gefunden.
sdc: Seagate Barracuda ST2000DM008-2UB102 2TB lt. smartctl SMR
sdd: Seagate Ironwolf ST4000VN008-2DR166 4TB keine Angabe.
sde: HGST Ultrastar HUS726040ALA610 4TB keine Angabe.
Mit smartctl 7.3
Wobei es natürlich GENAU die obige sdc ist die Ziel der
Kopier&Verschiebe-aktionen ist - und damit die SMR-Platte.
root@file:~# hdparm -t /dev/sdc
/dev/sdc:
Timing buffered disk reads: 634 MB in 3.00 seconds = 211.00 MB/sec
root@file:~# hdparm -T /dev/sdc
/dev/sdc:
Timing cached reads: 7202 MB in 2.00 seconds = 3608.68 MB/sec
root@file:~#
Hast du einen Tip für einen tauglichen Schreibtest der nicht Daten
zerstörend was aussagt?
Die Attribute dieser 2TB SMR Platte (als Zitat weils hier sonst umbricht):
> === START OF READ SMART DATA SECTION ===
> SMART Attributes Data Structure revision number: 10
> Vendor Specific SMART Attributes with Thresholds:
> ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
> 1 Raw_Read_Error_Rate 0x000f 076 066 006 Pre-fail Always - 43547546
> 3 Spin_Up_Time 0x0003 097 097 000 Pre-fail Always - 0
> 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 35
> 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0
> 7 Seek_Error_Rate 0x000f 063 060 045 Pre-fail Always - 2164449
> 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 105h+02m+45.426s
> 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0
> 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 37
> 183 Runtime_Bad_Block 0x0032 100 100 000 Old_age Always - 0
> 184 End-to-End_Error 0x0032 100 100 099 Old_age Always - 0
> 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0
> 188 Command_Timeout 0x0032 100 100 000 Old_age Always - 0 0 1
> 189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0
> 190 Airflow_Temperature_Cel 0x0022 058 057 040 Old_age Always - 42 (Min/Max 26/42)
> 191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always - 0
> 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 14
> 193 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 153
> 194 Temperature_Celsius 0x0022 042 043 000 Old_age Always - 42 (0 26 0 0 0)
> 195 Hardware_ECC_Recovered 0x001a 076 066 000 Old_age Always - 43547546
> 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0
> 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0
> 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0
> 240 Head_Flying_Hours 0x0000 100 253 000 Old_age Offline - 94h+23m+36.338s
> 241 Total_LBAs_Written 0x0000 100 253 000 Old_age Offline - 806322357
> 242 Total_LBAs_Read 0x0000 100 253 000 Old_age Offline - 1472797676
>> Ich habe hier aktuell eher den Eindruck das bei einem Transfer via LAN
>> von mehreren Gigabyte ZU diesem Host da irgendwas blockiert und dann
>> einen <timeout-zeitspanne> langen komplett-ausfall der LAN Anbindung
>> verursacht.
>
> Da kämen Packet-Loss - gibt aber nur einige Sekunden Pause - oder eben
> auch SATA Timeouts in Frage. Letztere können locker eine halbe Minute
> blockieren. Gefühlt würde ich auf letzteres tippen. Entweder matschige
> SATA-Verbindungen oder defekte Sektoren auf den Platten.
S.o. HW ECC Recovered ist zwar hoch aber es sind keine Reallocated
Sectors. Wie ich die Raw Read und Seek Errors bewerten soll weiß ich
grade nicht. Die Seek errors scheinen mir näher am Threshold zu sein als
die Raw Read errors. Nur, was heißt das, bei einer SMR-Platte?
>> Wie reagiert eigentlich ein systemd wenn z.b. der Samba abstirbt? Kann
>> es sein das der dann gleich ein ganzes bündel von units (an einem
>> LAN-Target?) stoppt und neu startet.
>
> Was zur Hölle ist ein LAN Target?
Ich meine diese systemd "targets" wie "multi-user". Ich weiß nicht ob
der auch eines für LAN kennt, es würde mich aber wundern wenn nicht.
Da nehme ich doch an das systemd z.b. beim Raus ziehen des
Netzwerk-kabels alles stoppt was da dran hängt, also ssh, samba u.s.w.
Oder eben, wenn ein Dienst aus dieser Kategorie (Target?) abkackt?
> Wenn der Samba Daemon stirbt sind alle Verbindungen und Sessions weg.
> Die Clients müssen sich dann neu Authentifizieren. Das geht
> üblicherweise automatisch.
Ja, das klappt auch. Nach <zeitablauf> kommt der Client auch sofort
wieder auf die Freigabe des SMB-Servers.
>> Bei den bisherigen Transfer-versuchen hat ein anschließendes ping auf
>> die IP generell über 100 bis ca. 150 versuche gemacht bis dann wieder
>> ein Echo zurück kam.
>
> Das _kann_ auf ein Netzwerk-Problem hindeuten. Es kann aber auch sein,
> dass der Rechner so blockiert ist, dass er selbst auf Ping nicht mehr
> antworten kann. Hänger auf dem Root-Volume können schon fast alles lahm
> legen.
Da ist mir nichts in den logs aufgefallen bis auf:
einen fehler beim laden des floppy-moduls.
Fehlermeldungen zu sp5100_tco die wohl 'watchdog' nachladen und nur bei
IPMI-Boards sinn machen sollen.
Beide sind jetzt blacklisted.
Und
[ 1.426603] pci 0000:00:13.1: OHCI: BIOS handoff failed (BIOS bug?) 00000184
[18.250663] ata3.00: Read log 0x00 page 0x00 failed, Emask 0x40
[18.250708] ata3.00: Read log 0x00 page 0x00 failed, Emask 0x40
Wobei ata3 warscheinlich die TEAM7 SSD mit 60 GB ist, meine Aktuelle
Bootplatte.
Smartctl sagt die hat kein Log.
>> Und ssh oder samba sind in der zeit ja auch nicht erreichbar. Der
>> Versuch liefert nur "no route to host"
>
> Dann ist sogar ARP verreckt. Kurzum, der IP-Adresse kann gar keine
> MAC-Adresse mehr zugeordnet werden. Hast du irgendeinen, der ARP kaputt
> machen will, z.B. über Spoofing? Zwei Rechner mit derselben IP wären
> auch so ein Klassiker. Die schnappen sich gegenseitig immer die MAC weg.
Ich hab den Alten Fileserver ausgeschaltet. Der hatte eine IP .50 und
der aktuelle die IP .200. Nur der name 'file' war bis eben in meinem
internen DNS noch der IP .50 zugeordnet.
Die Beiden Rechner haben aber eigene NICs und deren MAC sollte m.E. auch
unterschiedlich sein. Geändert habe ich sie jedenfalls nicht!
> Der ARP-Cache hält aber nicht sehr lange. Insofern kann das schon die
> Folge von Verbindungsproblemen sein.
> Ein kaputter NIC käme durchaus auch in Frage.
root@file:~# ip -s link show enp4s0
2: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel
state UP mode DEFAULT group default qlen 1000
link/ether 00:24:1d:cf:de:cf brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped missed mcast
9565992620 6459295 0 20548 1943 10025
TX: bytes packets errors dropped carrier collsns
299367582 1463211 0 0 0 0
root@file:~# uptime
19:32:54 up 5:43, 5 users, load average: 0,10, 0,04, 0,04
Ich komme mit der aufruf-nomenklatur von 'ip' immer noch nicht so
richtig klar. Wenn du einen Tip hast erweiterte Statistiken zu bekommen,
gerne.
Dropped und missed sind nicht null. Aber bei über 5 Stunden, und evtl.
vorher noch aktivem paketfilter der evtl. vorher incoming ablehnte -
aber offenbar nicht smb...???
>> Falls aber ein samba-fehler via systemd zu einem kompletten DoS führt
>> dann hätte das gleiche auch mit einem OMV-NAS o.ä. passieren können.
>> Denn der steckt da ebenfalls drin.
>
> Nein, der würde sofort neu starten, jedenfalls ein paar mal. Das dauert
> allenfalls Sekunden.
Die Zeit ohne LAN scheint generell im Minutenbereich zu liegen. Und
bisher wurde die Verbindung ganz automatisch wieder aufgebaut.
Jetzt habe ich aktuell keine Idee was ich noch testen kann, außer die
Schreibleistung der Platten...
> Am 31.01.24 um 16:12 schrieb Kay Martinen:
>>> Die Zielplatte ist aber nicht zufällig ein SMR-Exemplar?
>>
>> Das ist möglich, ja. Allerdings wäre die hier weitgehend leer.
>
> Das ist egal. SMR-Platten haben eine übelste Write-Amplification. Die
> müssen oft ein Vielfaches der übertragenen Datenmenge schreiben und sind
> dadurch um den entsprechenden Faktor langsamer. Genaueres hängt
Aber die "Schreiben" doch dann nur intern spuren neu wenn etwas
>>> Die Zielplatte ist aber nicht zufällig ein SMR-Exemplar?
>>
>> Das ist möglich, ja. Allerdings wäre die hier weitgehend leer.
>
> Das ist egal. SMR-Platten haben eine übelste Write-Amplification. Die
> müssen oft ein Vielfaches der übertragenen Datenmenge schreiben und sind
> dadurch um den entsprechenden Faktor langsamer. Genaueres hängt
hinzugefügt würde. Das geht doch m.E. nicht über den Bus.
> natürlich vom jeweiligen Anwendungsszenario ab. Aber selbst wenn man
> größere Blöcke am Stück schreibt, müssen für das Schreiben der Metadaten
> schnell mal 8MB geschrieben werden anstatt 4kb.
Die vier Platten hier sind:
sdb: Hitachi HUA722020ALA331 2 TB Keine Angabe ob SMR gefunden.
sdc: Seagate Barracuda ST2000DM008-2UB102 2TB lt. smartctl SMR
sdd: Seagate Ironwolf ST4000VN008-2DR166 4TB keine Angabe.
sde: HGST Ultrastar HUS726040ALA610 4TB keine Angabe.
Mit smartctl 7.3
Wobei es natürlich GENAU die obige sdc ist die Ziel der
Kopier&Verschiebe-aktionen ist - und damit die SMR-Platte.
root@file:~# hdparm -t /dev/sdc
/dev/sdc:
Timing buffered disk reads: 634 MB in 3.00 seconds = 211.00 MB/sec
root@file:~# hdparm -T /dev/sdc
/dev/sdc:
Timing cached reads: 7202 MB in 2.00 seconds = 3608.68 MB/sec
root@file:~#
Hast du einen Tip für einen tauglichen Schreibtest der nicht Daten
zerstörend was aussagt?
Die Attribute dieser 2TB SMR Platte (als Zitat weils hier sonst umbricht):
> === START OF READ SMART DATA SECTION ===
> SMART Attributes Data Structure revision number: 10
> Vendor Specific SMART Attributes with Thresholds:
> ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
> 1 Raw_Read_Error_Rate 0x000f 076 066 006 Pre-fail Always - 43547546
> 3 Spin_Up_Time 0x0003 097 097 000 Pre-fail Always - 0
> 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 35
> 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0
> 7 Seek_Error_Rate 0x000f 063 060 045 Pre-fail Always - 2164449
> 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 105h+02m+45.426s
> 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0
> 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 37
> 183 Runtime_Bad_Block 0x0032 100 100 000 Old_age Always - 0
> 184 End-to-End_Error 0x0032 100 100 099 Old_age Always - 0
> 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0
> 188 Command_Timeout 0x0032 100 100 000 Old_age Always - 0 0 1
> 189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0
> 190 Airflow_Temperature_Cel 0x0022 058 057 040 Old_age Always - 42 (Min/Max 26/42)
> 191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always - 0
> 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 14
> 193 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 153
> 194 Temperature_Celsius 0x0022 042 043 000 Old_age Always - 42 (0 26 0 0 0)
> 195 Hardware_ECC_Recovered 0x001a 076 066 000 Old_age Always - 43547546
> 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0
> 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0
> 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0
> 240 Head_Flying_Hours 0x0000 100 253 000 Old_age Offline - 94h+23m+36.338s
> 241 Total_LBAs_Written 0x0000 100 253 000 Old_age Offline - 806322357
> 242 Total_LBAs_Read 0x0000 100 253 000 Old_age Offline - 1472797676
>> Ich habe hier aktuell eher den Eindruck das bei einem Transfer via LAN
>> von mehreren Gigabyte ZU diesem Host da irgendwas blockiert und dann
>> einen <timeout-zeitspanne> langen komplett-ausfall der LAN Anbindung
>> verursacht.
>
> Da kämen Packet-Loss - gibt aber nur einige Sekunden Pause - oder eben
> auch SATA Timeouts in Frage. Letztere können locker eine halbe Minute
> blockieren. Gefühlt würde ich auf letzteres tippen. Entweder matschige
> SATA-Verbindungen oder defekte Sektoren auf den Platten.
Sectors. Wie ich die Raw Read und Seek Errors bewerten soll weiß ich
grade nicht. Die Seek errors scheinen mir näher am Threshold zu sein als
die Raw Read errors. Nur, was heißt das, bei einer SMR-Platte?
>> Wie reagiert eigentlich ein systemd wenn z.b. der Samba abstirbt? Kann
>> es sein das der dann gleich ein ganzes bündel von units (an einem
>> LAN-Target?) stoppt und neu startet.
>
> Was zur Hölle ist ein LAN Target?
der auch eines für LAN kennt, es würde mich aber wundern wenn nicht.
Da nehme ich doch an das systemd z.b. beim Raus ziehen des
Netzwerk-kabels alles stoppt was da dran hängt, also ssh, samba u.s.w.
Oder eben, wenn ein Dienst aus dieser Kategorie (Target?) abkackt?
> Wenn der Samba Daemon stirbt sind alle Verbindungen und Sessions weg.
> Die Clients müssen sich dann neu Authentifizieren. Das geht
> üblicherweise automatisch.
wieder auf die Freigabe des SMB-Servers.
>> Bei den bisherigen Transfer-versuchen hat ein anschließendes ping auf
>> die IP generell über 100 bis ca. 150 versuche gemacht bis dann wieder
>> ein Echo zurück kam.
>
> Das _kann_ auf ein Netzwerk-Problem hindeuten. Es kann aber auch sein,
> dass der Rechner so blockiert ist, dass er selbst auf Ping nicht mehr
> antworten kann. Hänger auf dem Root-Volume können schon fast alles lahm
> legen.
einen fehler beim laden des floppy-moduls.
Fehlermeldungen zu sp5100_tco die wohl 'watchdog' nachladen und nur bei
IPMI-Boards sinn machen sollen.
Beide sind jetzt blacklisted.
Und
[ 1.426603] pci 0000:00:13.1: OHCI: BIOS handoff failed (BIOS bug?) 00000184
[18.250663] ata3.00: Read log 0x00 page 0x00 failed, Emask 0x40
[18.250708] ata3.00: Read log 0x00 page 0x00 failed, Emask 0x40
Wobei ata3 warscheinlich die TEAM7 SSD mit 60 GB ist, meine Aktuelle
Bootplatte.
Smartctl sagt die hat kein Log.
>> Und ssh oder samba sind in der zeit ja auch nicht erreichbar. Der
>> Versuch liefert nur "no route to host"
>
> Dann ist sogar ARP verreckt. Kurzum, der IP-Adresse kann gar keine
> MAC-Adresse mehr zugeordnet werden. Hast du irgendeinen, der ARP kaputt
> machen will, z.B. über Spoofing? Zwei Rechner mit derselben IP wären
> auch so ein Klassiker. Die schnappen sich gegenseitig immer die MAC weg.
der aktuelle die IP .200. Nur der name 'file' war bis eben in meinem
internen DNS noch der IP .50 zugeordnet.
Die Beiden Rechner haben aber eigene NICs und deren MAC sollte m.E. auch
unterschiedlich sein. Geändert habe ich sie jedenfalls nicht!
> Der ARP-Cache hält aber nicht sehr lange. Insofern kann das schon die
> Folge von Verbindungsproblemen sein.
> Ein kaputter NIC käme durchaus auch in Frage.
2: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel
state UP mode DEFAULT group default qlen 1000
link/ether 00:24:1d:cf:de:cf brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped missed mcast
9565992620 6459295 0 20548 1943 10025
TX: bytes packets errors dropped carrier collsns
299367582 1463211 0 0 0 0
root@file:~# uptime
19:32:54 up 5:43, 5 users, load average: 0,10, 0,04, 0,04
Ich komme mit der aufruf-nomenklatur von 'ip' immer noch nicht so
richtig klar. Wenn du einen Tip hast erweiterte Statistiken zu bekommen,
gerne.
Dropped und missed sind nicht null. Aber bei über 5 Stunden, und evtl.
vorher noch aktivem paketfilter der evtl. vorher incoming ablehnte -
aber offenbar nicht smb...???
>> Falls aber ein samba-fehler via systemd zu einem kompletten DoS führt
>> dann hätte das gleiche auch mit einem OMV-NAS o.ä. passieren können.
>> Denn der steckt da ebenfalls drin.
>
> Nein, der würde sofort neu starten, jedenfalls ein paar mal. Das dauert
> allenfalls Sekunden.
bisher wurde die Verbindung ganz automatisch wieder aufgebaut.
Jetzt habe ich aktuell keine Idee was ich noch testen kann, außer die
Schreibleistung der Platten...
Marcel Mueller
Feb 1, 2024, 1:36:21 PM2/1/24
to
Am 31.01.24 um 20:22 schrieb Kay Martinen:
Das ist am Ende ein Read-Modify-Write Zyklus. Also alle Spuren eines
SMR-Bandes lesen, Änderungen einpflegen, Band wieder schreiben.
Angenommen das Band hat nur 8 Spuren, dann kostet die Nummer 16
Umdrehungen, also knapp 0,2s. Und das, wenn es dumm läuft für einen 4k
Block vom Verzeichniseintrag - die Festplatte in meinem 486-er war dabei
schneller.
Wenn größere Böcke am Stück geschrieben werden, wird das natürlich
deutlich effizienter. Am Ende kommt halt irgendein Gemisch raus.
>> natürlich vom jeweiligen Anwendungsszenario ab. Aber selbst wenn man
>> größere Blöcke am Stück schreibt, müssen für das Schreiben der Metadaten
>> schnell mal 8MB geschrieben werden anstatt 4kb.
>
> Also quasi halb so schnell wie nicht-SMR Platten erwartbar.
Ähm, eher 4000-mal für diesen Fall.
1. kb vs. MB, 2. müssen die Daten, die neu geschrieben werden, erst mal
gelesen werden.
> sdc: Seagate Barracuda ST2000DM008-2UB102 2TB lt. smartctl SMR
Mein Beileid.
> sdd: Seagate Ironwolf ST4000VN008-2DR166 4TB keine Angabe.
Ironwolf taugt etwas. Die haben CMR.
Die anderen kenne ich nicht.
> Wobei es natürlich GENAU die obige sdc ist die Ziel der
> Kopier&Verschiebe-aktionen ist - und damit die SMR-Platte.
Dann kennst du eine Ursache. Viel mehr als USB2-Geschwindigkeit ist in
den meisten Szenarien nicht zu erwarten.
> root@file:~# hdparm -t /dev/sdc
>
> /dev/sdc:
> Timing buffered disk reads: 634 MB in 3.00 seconds = 211.00 MB/sec
> root@file:~# hdparm -T /dev/sdc
>
> /dev/sdc:
> Timing cached reads: 7202 MB in 2.00 seconds = 3608.68 MB/sec
> root@file:~#
Die Werte sind unrealistisch. Eine Festplatte, die 3GB/s schafft hat es
noch nie gegeben.
Des weiteren sind SMR-Platten _beim Lesen_ genauso schnell wie CMR. Nur
beim Schreiben brechen sie ein.
Und last but not least ist eine SMR Platte beim Schreiben großer Blöcke
am Stück schlau genug, zu erkennen, dass die alten Daten komplett
überschrieben werden und daher nicht gesichert werden müssen. Auch dann
ist die Platte schnell. Das kommt in der Praxis aber eben nicht in
Reinform vor. Und selbst wenn nur jeder zweite Zurgriff ein kleiner
Block ist, bricht die Übertragungsrate schon auf etwa die Hälfte ein.
> Hast du einen Tip für einen tauglichen Schreibtest der nicht Daten
> zerstörend was aussagt?
Dateien von einer anderen Platte auf diese Platte kopieren (lokal).
> Die Attribute dieser 2TB SMR Platte (als Zitat weils hier sonst umbricht):
Bricht trotzdem um. :-)
Auffällig ist allenfalls das hier:
>> 7 Seek_Error_Rate 0x000f 063 060 045 Pre-fail
>> Always - 2164449
Die Platte braucht offenbar häufig mehrere Anläufe, um überhaupt die
Richtige Spur zu finden. Das ist bei modernen Platten leider fast die
Regel. Da wird nur noch Spielzeug verkauft.
Es kann aber durch Vibrationen oder Temperaturschwankungen verstärkt
werden. NoVibes-Rahmen sind das schlimmste.
>> 195 Hardware_ECC_Recovered 0x001a 076 066 000 Old_age
>> Always - 43547546
Das ist auch nicht so prickelnd. Aber es sind zumindest keine Daten
verloren gegangen. Die ECC-Fehler können aber auch Lesezugriffe etwas
verlangsamen.
> S.o. HW ECC Recovered ist zwar hoch aber es sind keine Reallocated
> Sectors. Wie ich die Raw Read und Seek Errors bewerten soll weiß ich
> grade nicht. Die Seek errors scheinen mir näher am Threshold zu sein als
> die Raw Read errors. Nur, was heißt das, bei einer SMR-Platte?
Das gleiche wie bei anderen Platten. ;-)
>>> Wie reagiert eigentlich ein systemd wenn z.b. der Samba abstirbt? Kann
>>> es sein das der dann gleich ein ganzes bündel von units (an einem
>>> LAN-Target?) stoppt und neu startet.
>>
>> Was zur Hölle ist ein LAN Target?
>
> Ich meine diese systemd "targets" wie "multi-user". Ich weiß nicht ob
> der auch eines für LAN kennt, es würde mich aber wundern wenn nicht.
Ja, mit network gibt es eines, damit davon Abhängige Dienste wie
NFS-Mounts erst danach starten.
> Da nehme ich doch an das systemd z.b. beim Raus ziehen des
> Netzwerk-kabels alles stoppt was da dran hängt, also ssh, samba u.s.w.
Nein, das tut er keinesfalls. Das gibt einfach eine Störung.
Da ist eher der Networkmanager ein Problem, der womöglich die IP-Adresse
und die Routen löscht.
Ich deinstalliere den oft bei festen Rechnern (oder VMs) und weise feste
IPs zu.
> Oder eben, wenn ein Dienst aus dieser Kategorie (Target?) abkackt?
Targets sind keine Dienste. Das sind nur logische Punkte, für deren
Erreichung Bedingungen erfüllt sein müssen.
> Ich komme mit der aufruf-nomenklatur von 'ip' immer noch nicht so
> richtig klar. Wenn du einen Tip hast erweiterte Statistiken zu bekommen,
> gerne.
Keine Ahnung.
> Die Zeit ohne LAN scheint generell im Minutenbereich zu liegen. Und
> bisher wurde die Verbindung ganz automatisch wieder aufgebaut.
Da raucht wirklich etwas ab. Vielleicht man einen Netzwerksniffer
mitlaufen lassen.
Marcel
> Am 31.01.24 um 18:55 schrieb Marcel Mueller:
>> Am 31.01.24 um 16:12 schrieb Kay Martinen:
>>>> Die Zielplatte ist aber nicht zufällig ein SMR-Exemplar?
>>>
>>> Das ist möglich, ja. Allerdings wäre die hier weitgehend leer.
>>
>> Das ist egal. SMR-Platten haben eine übelste Write-Amplification. Die
>> müssen oft ein Vielfaches der übertragenen Datenmenge schreiben und sind
>> dadurch um den entsprechenden Faktor langsamer. Genaueres hängt
>
> Aber die "Schreiben" doch dann nur intern spuren neu wenn etwas
> hinzugefügt würde. Das geht doch m.E. nicht über den Bus.
Nein, aber der Bus ist schneller als das Medium. Letzteres gibt den Takt an.
>> Am 31.01.24 um 16:12 schrieb Kay Martinen:
>>>> Die Zielplatte ist aber nicht zufällig ein SMR-Exemplar?
>>>
>>> Das ist möglich, ja. Allerdings wäre die hier weitgehend leer.
>>
>> Das ist egal. SMR-Platten haben eine übelste Write-Amplification. Die
>> müssen oft ein Vielfaches der übertragenen Datenmenge schreiben und sind
>> dadurch um den entsprechenden Faktor langsamer. Genaueres hängt
>
> Aber die "Schreiben" doch dann nur intern spuren neu wenn etwas
> hinzugefügt würde. Das geht doch m.E. nicht über den Bus.
Das ist am Ende ein Read-Modify-Write Zyklus. Also alle Spuren eines
SMR-Bandes lesen, Änderungen einpflegen, Band wieder schreiben.
Angenommen das Band hat nur 8 Spuren, dann kostet die Nummer 16
Umdrehungen, also knapp 0,2s. Und das, wenn es dumm läuft für einen 4k
Block vom Verzeichniseintrag - die Festplatte in meinem 486-er war dabei
schneller.
Wenn größere Böcke am Stück geschrieben werden, wird das natürlich
deutlich effizienter. Am Ende kommt halt irgendein Gemisch raus.
>> natürlich vom jeweiligen Anwendungsszenario ab. Aber selbst wenn man
>> größere Blöcke am Stück schreibt, müssen für das Schreiben der Metadaten
>> schnell mal 8MB geschrieben werden anstatt 4kb.
>
> Also quasi halb so schnell wie nicht-SMR Platten erwartbar.
1. kb vs. MB, 2. müssen die Daten, die neu geschrieben werden, erst mal
gelesen werden.
> sdc: Seagate Barracuda ST2000DM008-2UB102 2TB lt. smartctl SMR
> sdd: Seagate Ironwolf ST4000VN008-2DR166 4TB keine Angabe.
Die anderen kenne ich nicht.
> Wobei es natürlich GENAU die obige sdc ist die Ziel der
> Kopier&Verschiebe-aktionen ist - und damit die SMR-Platte.
den meisten Szenarien nicht zu erwarten.
> root@file:~# hdparm -t /dev/sdc
>
> /dev/sdc:
> Timing buffered disk reads: 634 MB in 3.00 seconds = 211.00 MB/sec
> root@file:~# hdparm -T /dev/sdc
>
> /dev/sdc:
> Timing cached reads: 7202 MB in 2.00 seconds = 3608.68 MB/sec
> root@file:~#
noch nie gegeben.
Des weiteren sind SMR-Platten _beim Lesen_ genauso schnell wie CMR. Nur
beim Schreiben brechen sie ein.
Und last but not least ist eine SMR Platte beim Schreiben großer Blöcke
am Stück schlau genug, zu erkennen, dass die alten Daten komplett
überschrieben werden und daher nicht gesichert werden müssen. Auch dann
ist die Platte schnell. Das kommt in der Praxis aber eben nicht in
Reinform vor. Und selbst wenn nur jeder zweite Zurgriff ein kleiner
Block ist, bricht die Übertragungsrate schon auf etwa die Hälfte ein.
> Hast du einen Tip für einen tauglichen Schreibtest der nicht Daten
> zerstörend was aussagt?
> Die Attribute dieser 2TB SMR Platte (als Zitat weils hier sonst umbricht):
Auffällig ist allenfalls das hier:
>> 7 Seek_Error_Rate 0x000f 063 060 045 Pre-fail
>> Always - 2164449
Richtige Spur zu finden. Das ist bei modernen Platten leider fast die
Regel. Da wird nur noch Spielzeug verkauft.
Es kann aber durch Vibrationen oder Temperaturschwankungen verstärkt
werden. NoVibes-Rahmen sind das schlimmste.
>> 195 Hardware_ECC_Recovered 0x001a 076 066 000 Old_age
>> Always - 43547546
verloren gegangen. Die ECC-Fehler können aber auch Lesezugriffe etwas
verlangsamen.
> S.o. HW ECC Recovered ist zwar hoch aber es sind keine Reallocated
> Sectors. Wie ich die Raw Read und Seek Errors bewerten soll weiß ich
> grade nicht. Die Seek errors scheinen mir näher am Threshold zu sein als
> die Raw Read errors. Nur, was heißt das, bei einer SMR-Platte?
>>> Wie reagiert eigentlich ein systemd wenn z.b. der Samba abstirbt? Kann
>>> es sein das der dann gleich ein ganzes bündel von units (an einem
>>> LAN-Target?) stoppt und neu startet.
>>
>> Was zur Hölle ist ein LAN Target?
>
> Ich meine diese systemd "targets" wie "multi-user". Ich weiß nicht ob
> der auch eines für LAN kennt, es würde mich aber wundern wenn nicht.
NFS-Mounts erst danach starten.
> Da nehme ich doch an das systemd z.b. beim Raus ziehen des
> Netzwerk-kabels alles stoppt was da dran hängt, also ssh, samba u.s.w.
Da ist eher der Networkmanager ein Problem, der womöglich die IP-Adresse
und die Routen löscht.
Ich deinstalliere den oft bei festen Rechnern (oder VMs) und weise feste
IPs zu.
> Oder eben, wenn ein Dienst aus dieser Kategorie (Target?) abkackt?
Erreichung Bedingungen erfüllt sein müssen.
> Ich komme mit der aufruf-nomenklatur von 'ip' immer noch nicht so
> richtig klar. Wenn du einen Tip hast erweiterte Statistiken zu bekommen,
> gerne.
> Die Zeit ohne LAN scheint generell im Minutenbereich zu liegen. Und
> bisher wurde die Verbindung ganz automatisch wieder aufgebaut.
mitlaufen lassen.
Marcel
Kay Martinen
Feb 1, 2024, 5:40:03 PM2/1/24
to
Am 01.02.24 um 19:36 schrieb Marcel Mueller:
drauf liegen die ich aufnahm, bei Gelegenheit sortiere und Schneide und
ansonsten einfach nur sehe wenn mir danach ist.
Wenn die abkacken sollte ist es verschmerzbar.
>> Wobei es natürlich GENAU die obige sdc ist die Ziel der
>> Kopier&Verschiebe-aktionen ist - und damit die SMR-Platte.
>
> Dann kennst du eine Ursache. Viel mehr als USB2-Geschwindigkeit ist in
> den meisten Szenarien nicht zu erwarten.
Heute waren es via LAN ca. 34MB/sec. S.u.
>> root@file:~# hdparm -t /dev/sdc
>>
>> /dev/sdc:
>> Timing buffered disk reads: 634 MB in 3.00 seconds = 211.00 MB/sec
>> root@file:~# hdparm -T /dev/sdc
>>
>> /dev/sdc:
>> Timing cached reads: 7202 MB in 2.00 seconds = 3608.68 MB/sec
>> root@file:~#
>
> Die Werte sind unrealistisch. Eine Festplatte, die 3GB/s schafft hat es
> noch nie gegeben.
Ja, das waren auch cached reads. Ich hab einfach allen output kopiert.
Die Platte selbst meldet SATA 6G aber sie hängt an einem SATA 3 Port.
Leider sind nur 2 der 8 SATA Ports welche mit 6G.
Ich weiß auch das diese Platten kaum diese Linkspeed schaffen werden.
> Des weiteren sind SMR-Platten _beim Lesen_ genauso schnell wie CMR. Nur
> beim Schreiben brechen sie ein.
Wenn man das z.b. mit dem mc in einem Terminal machte. Der zeigt die
Transferrate dabei immerhin an. Mit dd möchte ich ungern auf einem
dateisystem spielen. ;)
>> Die Attribute dieser 2TB SMR Platte (als Zitat weils hier sonst umbricht):
den anderen 3 Platten im gleichen Käfig, allerdings mit Abstand
dazwischen, ca. halbe bis ganze Plattenhöhe Luft.
>> Da nehme ich doch an das systemd z.b. beim Raus ziehen des
>> Netzwerk-kabels alles stoppt was da dran hängt, also ssh, samba u.s.w.
>
> Nein, das tut er keinesfalls. Das gibt einfach eine Störung.
> Da ist eher der Networkmanager ein Problem, der womöglich die IP-Adresse
> und die Routen löscht.
Ich hab die IP im NM wohl auf Manuell konfiguriert eingestellt. Bisher
ließ ich das so. Auch weil ich nicht weiß ob eine old-school Einstellung
via /etc/network/interfaces bei dessen entfernung doch immer noch
irgendwie vom Desktop aus geändert werden könnte. Ist nur'n
Bequemlichkeits-ding. Wenn der das Problem sein sollte dann werf ich den
auch raus.
>> Die Zeit ohne LAN scheint generell im Minutenbereich zu liegen. Und
>> bisher wurde die Verbindung ganz automatisch wieder aufgebaut.
>
> Da raucht wirklich etwas ab. Vielleicht man einen Netzwerksniffer
> mitlaufen lassen.
Hmm, Aktuell: Ich hab die Onboard-NIC heute stillgelegt; und auch den
Floppy-controller; und eine PCIe x1 LAN Karte gesteckt. Die ebenfalls
den r8169 Treiber benutzt. statt enp4s0 ist es nun enp2s0.
Bisher habe ich mehrmals 5-15 GB via LAN kopiert auf diese 2 TB SMR
Platte. Und heute gab es bei genau NULL dieser Aktionen einen Fehler.
Allerdings muß ich noch zugeben das beim Besuch des BIOS auffiel das
dort eine 3.5" Floppy DOCH immer noch eingetragen war, und die stand
auch an 3. Stelle in der Boot-sequenz. Sorry, mein Lapsus. :-/
Ich hab hier eine gut gefüllte 1 TB Platte mit Serien die ich noch
kopieren will. Mal sehen ob sich dabei noch Probleme auf tun.
Das "keine Fehler" heißt übrigens ebenfalls "keine Aussetzer". Es könnte
also doch die Onboard-NIC sein. Evtl. hat die nur ein Problem mit
höheren Datenmengen.
Stats:
root@file:~# ip -s link show enp2s0
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel
root@file:~# uptime
23:29:59 up 9:25, 4 users, load average: 0,03, 0,01, 0,00
> Am 31.01.24 um 20:22 schrieb Kay Martinen:
>> Am 31.01.24 um 18:55 schrieb Marcel Mueller:
>> Am 31.01.24 um 18:55 schrieb Marcel Mueller:
>> sdc: Seagate Barracuda ST2000DM008-2UB102 2TB lt. smartctl SMR
>
> Mein Beileid.
Sie war Billig, Gebraucht, refurbished. Und es sollen nur Fernsehserien
>
> Mein Beileid.
drauf liegen die ich aufnahm, bei Gelegenheit sortiere und Schneide und
ansonsten einfach nur sehe wenn mir danach ist.
Wenn die abkacken sollte ist es verschmerzbar.
>> Wobei es natürlich GENAU die obige sdc ist die Ziel der
>> Kopier&Verschiebe-aktionen ist - und damit die SMR-Platte.
>
> Dann kennst du eine Ursache. Viel mehr als USB2-Geschwindigkeit ist in
> den meisten Szenarien nicht zu erwarten.
>> root@file:~# hdparm -t /dev/sdc
>>
>> /dev/sdc:
>> Timing buffered disk reads: 634 MB in 3.00 seconds = 211.00 MB/sec
>> root@file:~# hdparm -T /dev/sdc
>>
>> /dev/sdc:
>> Timing cached reads: 7202 MB in 2.00 seconds = 3608.68 MB/sec
>> root@file:~#
>
> Die Werte sind unrealistisch. Eine Festplatte, die 3GB/s schafft hat es
> noch nie gegeben.
Die Platte selbst meldet SATA 6G aber sie hängt an einem SATA 3 Port.
Leider sind nur 2 der 8 SATA Ports welche mit 6G.
Ich weiß auch das diese Platten kaum diese Linkspeed schaffen werden.
> Des weiteren sind SMR-Platten _beim Lesen_ genauso schnell wie CMR. Nur
> beim Schreiben brechen sie ein.
>> Hast du einen Tip für einen tauglichen Schreibtest der nicht Daten
>> zerstörend was aussagt?
>
> Dateien von einer anderen Platte auf diese Platte kopieren (lokal).
Ich bin nicht sicher ob das wirklich vergleichbare Ergebnisse lieferte.
>> zerstörend was aussagt?
>
> Dateien von einer anderen Platte auf diese Platte kopieren (lokal).
Wenn man das z.b. mit dem mc in einem Terminal machte. Der zeigt die
Transferrate dabei immerhin an. Mit dd möchte ich ungern auf einem
dateisystem spielen. ;)
>> Die Attribute dieser 2TB SMR Platte (als Zitat weils hier sonst umbricht):
> Auffällig ist allenfalls das hier:
>
>>> 7 Seek_Error_Rate 0x000f 063 060 045 Pre-fail
>>> Always - 2164449
>
> Die Platte braucht offenbar häufig mehrere Anläufe, um überhaupt die
> Richtige Spur zu finden. Das ist bei modernen Platten leider fast die
> Regel. Da wird nur noch Spielzeug verkauft.
> Es kann aber durch Vibrationen oder Temperaturschwankungen verstärkt
> werden. NoVibes-Rahmen sind das schlimmste.
Die ist fest verschraubt und da wackelt auch nichts. Sie steckt nur mit
>
>>> 7 Seek_Error_Rate 0x000f 063 060 045 Pre-fail
>>> Always - 2164449
>
> Die Platte braucht offenbar häufig mehrere Anläufe, um überhaupt die
> Richtige Spur zu finden. Das ist bei modernen Platten leider fast die
> Regel. Da wird nur noch Spielzeug verkauft.
> Es kann aber durch Vibrationen oder Temperaturschwankungen verstärkt
> werden. NoVibes-Rahmen sind das schlimmste.
den anderen 3 Platten im gleichen Käfig, allerdings mit Abstand
dazwischen, ca. halbe bis ganze Plattenhöhe Luft.
>> Da nehme ich doch an das systemd z.b. beim Raus ziehen des
>> Netzwerk-kabels alles stoppt was da dran hängt, also ssh, samba u.s.w.
>
> Nein, das tut er keinesfalls. Das gibt einfach eine Störung.
> Da ist eher der Networkmanager ein Problem, der womöglich die IP-Adresse
> und die Routen löscht.
ließ ich das so. Auch weil ich nicht weiß ob eine old-school Einstellung
via /etc/network/interfaces bei dessen entfernung doch immer noch
irgendwie vom Desktop aus geändert werden könnte. Ist nur'n
Bequemlichkeits-ding. Wenn der das Problem sein sollte dann werf ich den
auch raus.
>> Die Zeit ohne LAN scheint generell im Minutenbereich zu liegen. Und
>> bisher wurde die Verbindung ganz automatisch wieder aufgebaut.
>
> Da raucht wirklich etwas ab. Vielleicht man einen Netzwerksniffer
> mitlaufen lassen.
Floppy-controller; und eine PCIe x1 LAN Karte gesteckt. Die ebenfalls
den r8169 Treiber benutzt. statt enp4s0 ist es nun enp2s0.
Bisher habe ich mehrmals 5-15 GB via LAN kopiert auf diese 2 TB SMR
Platte. Und heute gab es bei genau NULL dieser Aktionen einen Fehler.
Allerdings muß ich noch zugeben das beim Besuch des BIOS auffiel das
dort eine 3.5" Floppy DOCH immer noch eingetragen war, und die stand
auch an 3. Stelle in der Boot-sequenz. Sorry, mein Lapsus. :-/
Ich hab hier eine gut gefüllte 1 TB Platte mit Serien die ich noch
kopieren will. Mal sehen ob sich dabei noch Probleme auf tun.
Das "keine Fehler" heißt übrigens ebenfalls "keine Aussetzer". Es könnte
also doch die Onboard-NIC sein. Evtl. hat die nur ein Problem mit
höheren Datenmengen.
Stats:
root@file:~# ip -s link show enp2s0
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel
state UP mode DEFAULT group default qlen 1000
link/ether 00:e0:4c:68:04:fd brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped missed mcast
29746768045 21852150 0 33878 113 12474
TX: bytes packets errors dropped carrier collsns
7804048312 10530318 0 0 0 0
root@file:~# uptime
23:29:59 up 9:25, 4 users, load average: 0,03, 0,01, 0,00
Marcel Mueller
Feb 2, 2024, 4:19:53 PM2/2/24
to
Am 01.02.24 um 23:32 schrieb Kay Martinen:
Für das Lagern von Filmen sind solche Platten an sich schon geeignet.
Beim Aufnehmen kann es manchmal eng werden, wenn die Puffer zu klein sind.
>> Dann kennst du eine Ursache. Viel mehr als USB2-Geschwindigkeit ist in
>> den meisten Szenarien nicht zu erwarten.
>
> Heute waren es via LAN ca. 34MB/sec. S.u.
Das hört sich vernünftig an.
> Ja, das waren auch cached reads. Ich hab einfach allen output kopiert.
> Die Platte selbst meldet SATA 6G aber sie hängt an einem SATA 3 Port.
> Leider sind nur 2 der 8 SATA Ports welche mit 6G.
>
> Ich weiß auch das diese Platten kaum diese Linkspeed schaffen werden.
SATA 3G spart Strom. Die 6G Port-Treiber ziehen ganz ordentlich.
>>> Hast du einen Tip für einen tauglichen Schreibtest der nicht Daten
>>> zerstörend was aussagt?
>>
>> Dateien von einer anderen Platte auf diese Platte kopieren (lokal).
>
> Ich bin nicht sicher ob das wirklich vergleichbare Ergebnisse lieferte.
> Wenn man das z.b. mit dem mc in einem Terminal machte. Der zeigt die
> Transferrate dabei immerhin an. Mit dd möchte ich ungern auf einem
> dateisystem spielen. ;)
Wer sagt, dass du ein Block-Device als Ziel verwenden sollst. Eine
normale Datei tut's auch. ;-)
bs=... nicht vergessen.
> Bisher habe ich mehrmals 5-15 GB via LAN kopiert auf diese 2 TB SMR
> Platte. Und heute gab es bei genau NULL dieser Aktionen einen Fehler.
Also doch Hardware.
> Allerdings muß ich noch zugeben das beim Besuch des BIOS auffiel das
> dort eine 3.5" Floppy DOCH immer noch eingetragen war, und die stand
> auch an 3. Stelle in der Boot-sequenz. Sorry, mein Lapsus. :-/
Das dürfte wohl kaum Performance kosten. ;-)
Marcel
> Sie war Billig, Gebraucht, refurbished. Und es sollen nur Fernsehserien
> drauf liegen die ich aufnahm, bei Gelegenheit sortiere und Schneide und
> ansonsten einfach nur sehe wenn mir danach ist.
>
> Wenn die abkacken sollte ist es verschmerzbar.
Auf die Lebensdauer hat SMR eigentlich keinen Einfluss.
> drauf liegen die ich aufnahm, bei Gelegenheit sortiere und Schneide und
> ansonsten einfach nur sehe wenn mir danach ist.
>
> Wenn die abkacken sollte ist es verschmerzbar.
Für das Lagern von Filmen sind solche Platten an sich schon geeignet.
Beim Aufnehmen kann es manchmal eng werden, wenn die Puffer zu klein sind.
>> Dann kennst du eine Ursache. Viel mehr als USB2-Geschwindigkeit ist in
>> den meisten Szenarien nicht zu erwarten.
>
> Heute waren es via LAN ca. 34MB/sec. S.u.
> Ja, das waren auch cached reads. Ich hab einfach allen output kopiert.
> Die Platte selbst meldet SATA 6G aber sie hängt an einem SATA 3 Port.
> Leider sind nur 2 der 8 SATA Ports welche mit 6G.
>
> Ich weiß auch das diese Platten kaum diese Linkspeed schaffen werden.
>>> Hast du einen Tip für einen tauglichen Schreibtest der nicht Daten
>>> zerstörend was aussagt?
>>
>> Dateien von einer anderen Platte auf diese Platte kopieren (lokal).
>
> Ich bin nicht sicher ob das wirklich vergleichbare Ergebnisse lieferte.
> Wenn man das z.b. mit dem mc in einem Terminal machte. Der zeigt die
> Transferrate dabei immerhin an. Mit dd möchte ich ungern auf einem
> dateisystem spielen. ;)
normale Datei tut's auch. ;-)
bs=... nicht vergessen.
> Bisher habe ich mehrmals 5-15 GB via LAN kopiert auf diese 2 TB SMR
> Platte. Und heute gab es bei genau NULL dieser Aktionen einen Fehler.
> Allerdings muß ich noch zugeben das beim Besuch des BIOS auffiel das
> dort eine 3.5" Floppy DOCH immer noch eingetragen war, und die stand
> auch an 3. Stelle in der Boot-sequenz. Sorry, mein Lapsus. :-/
Marcel
Kay Martinen
Feb 2, 2024, 5:20:03 PM2/2/24
to
Am 02.02.24 um 22:19 schrieb Marcel Mueller:
Obwohl ich heute dran denken mußte das es interessant wäre dort 1-2
Skystar Karten rein zu stecken und einen vdr oder vorzugsweise
TV-Headend drauf zu setzen. Allerdings waren die vergangenen Versuche
damit alle eher erfolglos ob und fraglich ob es nun an SCR liegt oder nicht.
Und ob das mit dem aktuellen kernel 6.x dort überhaupt funktioniert...
Die Frontend oder demod-treiber zu der Karte sind ja etwas "speziell".
>>> Dateien von einer anderen Platte auf diese Platte kopieren (lokal).
>>
>> Bisher habe ich mehrmals 5-15 GB via LAN kopiert auf diese 2 TB SMR
>> Platte. Und heute gab es bei genau NULL dieser Aktionen einen Fehler.
>
> Also doch Hardware.
Die der Onboard-NIC ja. So scheint es.
>> Allerdings muß ich noch zugeben das beim Besuch des BIOS auffiel das
>> dort eine 3.5" Floppy DOCH immer noch eingetragen war, und die stand
>> auch an 3. Stelle in der Boot-sequenz. Sorry, mein Lapsus. :-/
>
> Das dürfte wohl kaum Performance kosten. ;-)
Jedenfalls eliminiert es fehlermeldungen die einen von wesentlicherem
ablenken könnten.
> Am 01.02.24 um 23:32 schrieb Kay Martinen:
>> drauf liegen die ich aufnahm, bei Gelegenheit sortiere und Schneide und
>> ansonsten einfach nur sehe wenn mir danach ist.
>> ansonsten einfach nur sehe wenn mir danach ist.
> Für das Lagern von Filmen sind solche Platten an sich schon geeignet.
> Beim Aufnehmen kann es manchmal eng werden, wenn die Puffer zu klein sind.
Das ist auch keine Aufnahme-Platte, die ist nur Datenlager.
> Beim Aufnehmen kann es manchmal eng werden, wenn die Puffer zu klein sind.
Obwohl ich heute dran denken mußte das es interessant wäre dort 1-2
Skystar Karten rein zu stecken und einen vdr oder vorzugsweise
TV-Headend drauf zu setzen. Allerdings waren die vergangenen Versuche
damit alle eher erfolglos ob und fraglich ob es nun an SCR liegt oder nicht.
Und ob das mit dem aktuellen kernel 6.x dort überhaupt funktioniert...
Die Frontend oder demod-treiber zu der Karte sind ja etwas "speziell".
>>> Dateien von einer anderen Platte auf diese Platte kopieren (lokal).
>>
>> Transferrate dabei immerhin an. Mit dd möchte ich ungern auf einem
>> dateisystem spielen. ;)
>
> Wer sagt, dass du ein Block-Device als Ziel verwenden sollst. Eine
> normale Datei tut's auch. ;-)
> bs=... nicht vergessen.
Oh, ja da war ja was. und einen progress-indikator hatte dd ja auch.
>> dateisystem spielen. ;)
>
> Wer sagt, dass du ein Block-Device als Ziel verwenden sollst. Eine
> normale Datei tut's auch. ;-)
> bs=... nicht vergessen.
>> Bisher habe ich mehrmals 5-15 GB via LAN kopiert auf diese 2 TB SMR
>> Platte. Und heute gab es bei genau NULL dieser Aktionen einen Fehler.
>
> Also doch Hardware.
>> Allerdings muß ich noch zugeben das beim Besuch des BIOS auffiel das
>> dort eine 3.5" Floppy DOCH immer noch eingetragen war, und die stand
>> auch an 3. Stelle in der Boot-sequenz. Sorry, mein Lapsus. :-/
>
> Das dürfte wohl kaum Performance kosten. ;-)
ablenken könnten.
Marcel Mueller
Feb 3, 2024, 3:08:50 AM2/3/24
to
Am 02.02.24 um 23:11 schrieb Kay Martinen:
haben. Und PCIe-Karten bekommt man nahezu nicht. Und die wenigen, die es
zu Mondpreisen gibt, sind eigentlich auch nur USB-Chips.
Tatsächlich habe ich außer einer alten nVidia keine einzige PCIe-Karte,
in einem alten Board, wo der 3k-Monitor die Onboard R3000 doch etwas in
die Knie gezwungen hat. Moderne Boards haben eben auch alles, was man
braucht dabei.
Und an den USB-Tunern nervt mich das externe Netzteil. Wieder ein
24/7-Verbraucher, den man nicht sinnvoll abschalten kann. Bei den
eingebauten Skystars schließt man einfach das Device, wenn es nichts zu
tun gibt, und die schalten das LNB nebst Multiswitch ab.
>> Wer sagt, dass du ein Block-Device als Ziel verwenden sollst. Eine
>> normale Datei tut's auch. ;-)
>> bs=... nicht vergessen.
>
> Oh, ja da war ja was. und einen progress-indikator hatte dd ja auch.
Yep.
>>> Bisher habe ich mehrmals 5-15 GB via LAN kopiert auf diese 2 TB SMR
>>> Platte. Und heute gab es bei genau NULL dieser Aktionen einen Fehler.
>>
>> Also doch Hardware.
>
> Die der Onboard-NIC ja. So scheint es.
Oder die Verbindung derselben. Mglw. die Buchse oder eine Lötstelle
derselben.
Aber ich denke Samba ist jetzt wirklich entlastet.
Marcel
> Das ist auch keine Aufnahme-Platte, die ist nur Datenlager.
>
> Obwohl ich heute dran denken mußte das es interessant wäre dort 1-2
> Skystar Karten rein zu stecken und einen vdr oder vorzugsweise
> TV-Headend drauf zu setzen. Allerdings waren die vergangenen Versuche
> damit alle eher erfolglos ob und fraglich ob es nun an SCR liegt oder
> nicht.
> Und ob das mit dem aktuellen kernel 6.x dort überhaupt funktioniert...
> Die Frontend oder demod-treiber zu der Karte sind ja etwas "speziell".
Das größere Problem finde ich, dass aktuelle Boards keine PCI-Slots mehr
>
> Obwohl ich heute dran denken mußte das es interessant wäre dort 1-2
> Skystar Karten rein zu stecken und einen vdr oder vorzugsweise
> TV-Headend drauf zu setzen. Allerdings waren die vergangenen Versuche
> damit alle eher erfolglos ob und fraglich ob es nun an SCR liegt oder
> nicht.
> Und ob das mit dem aktuellen kernel 6.x dort überhaupt funktioniert...
> Die Frontend oder demod-treiber zu der Karte sind ja etwas "speziell".
haben. Und PCIe-Karten bekommt man nahezu nicht. Und die wenigen, die es
zu Mondpreisen gibt, sind eigentlich auch nur USB-Chips.
Tatsächlich habe ich außer einer alten nVidia keine einzige PCIe-Karte,
in einem alten Board, wo der 3k-Monitor die Onboard R3000 doch etwas in
die Knie gezwungen hat. Moderne Boards haben eben auch alles, was man
braucht dabei.
Und an den USB-Tunern nervt mich das externe Netzteil. Wieder ein
24/7-Verbraucher, den man nicht sinnvoll abschalten kann. Bei den
eingebauten Skystars schließt man einfach das Device, wenn es nichts zu
tun gibt, und die schalten das LNB nebst Multiswitch ab.
>> Wer sagt, dass du ein Block-Device als Ziel verwenden sollst. Eine
>> normale Datei tut's auch. ;-)
>> bs=... nicht vergessen.
>
> Oh, ja da war ja was. und einen progress-indikator hatte dd ja auch.
>>> Bisher habe ich mehrmals 5-15 GB via LAN kopiert auf diese 2 TB SMR
>>> Platte. Und heute gab es bei genau NULL dieser Aktionen einen Fehler.
>>
>> Also doch Hardware.
>
> Die der Onboard-NIC ja. So scheint es.
derselben.
Aber ich denke Samba ist jetzt wirklich entlastet.
Marcel
Kay Martinen
Feb 4, 2024, 4:10:03 PM2/4/24
to
Am 03.02.24 um 09:08 schrieb Marcel Mueller in d.c.o.u.n.s:
mehr neu weil ich kaum neues kaufe. So lange die Alte HW ihren Dienst tut.
> Moderne Boards haben eben auch alles, was man
> braucht dabei.
Und jede Menge Zeugs das man ggf. nicht braucht aber mit kaufen muss.
> Und an den USB-Tunern nervt mich das externe Netzteil. Wieder ein
> 24/7-Verbraucher, den man nicht sinnvoll abschalten kann. Bei den
Du kannst deren Netzteil an eine Steckdosen-Leiste hängen, via USB o.a.
abgeschaltet.
> eingebauten Skystars schließt man einfach das Device, wenn es nichts zu
> tun gibt, und die schalten das LNB nebst Multiswitch ab.
Das wöre hier irrelevant weil im Keller eh eine Batterie an Technirouter
Modulen steckt. Und jede Wohnung via SCR 4 Slots bekommt. "Etwas"
abschalten wäre da nur nachts drin wenn NIEMAND TV/Radio nutzte. Wobei
noch offen bliebe ob der LNB auch strom spart wenn alle TR in Standby
wären. Versorgt werden sie dennoch - aber immerhin vom Allgemeinstrom.
>>> Also doch Hardware.
>>
>> Die der Onboard-NIC ja. So scheint es.
>
> Oder die Verbindung derselben. Mglw. die Buchse oder eine Lötstelle
> derselben.
Am Kabel hab ich jetzt nicht gezupft auch wenn das sicher nicht
bombenfest steckt. Allerdings hat die Onboard-NIC vorher (Vor dem
Neu-Flashen der Firmware) auch gerne mal den Abraster gemacht. Sprich:
Trotz kabel drin und normalem Start einfach nicht aktiviert und auch
nicht nachträglich. Erst stromlos machen und eine Weile Warten und dann
gern mal etliches Drücken des Reset-Tasters hat die dann reaktiviert.
Davor war der auch gern mal aus und wollte sich nicht per Taster
einschalten lassen, sprang aber bei Stromzufuhr kurz an um wieder aus zu
bleiben.
Das alles ist sein dem FW-ReFlash nicht mehr aufgetreten. Das scheint
echt was gebracht zu haben. Nur die "AE Not Found ... " acpi-meldungen
beim boot gehen nicht weg. Dem Fehlen also offenbar immer noch
ACPI-Infos zu <irgendwas>
Könnte also IMO am ehesten ein Sporadischer Fehler der NIC sein, Buchse,
Lötstelle, tja.
> Aber ich denke Samba ist jetzt wirklich entlastet.
Scheint mir auch so. Darum XP & f'up2 d.c.o.u.l.h. mit Topic-wechsel
Kay
> Am 02.02.24 um 23:11 schrieb Kay Martinen:
>> Das ist auch keine Aufnahme-Platte, die ist nur Datenlager.
>>
>> Obwohl ich heute dran denken mußte das es interessant wäre dort 1-2
>> Skystar Karten rein zu stecken und einen vdr oder vorzugsweise
>> Das ist auch keine Aufnahme-Platte, die ist nur Datenlager.
>>
>> Obwohl ich heute dran denken mußte das es interessant wäre dort 1-2
>> Skystar Karten rein zu stecken und einen vdr oder vorzugsweise
>> Und ob das mit dem aktuellen kernel 6.x dort überhaupt funktioniert...
>> Die Frontend oder demod-treiber zu der Karte sind ja etwas "speziell".
>
> Das größere Problem finde ich, dass aktuelle Boards keine PCI-Slots mehr
Also ich hab noch genug Boards mit PCI. Aber die sind eben alle nicht
>> Die Frontend oder demod-treiber zu der Karte sind ja etwas "speziell".
>
> Das größere Problem finde ich, dass aktuelle Boards keine PCI-Slots mehr
mehr neu weil ich kaum neues kaufe. So lange die Alte HW ihren Dienst tut.
> Moderne Boards haben eben auch alles, was man
> braucht dabei.
> Und an den USB-Tunern nervt mich das externe Netzteil. Wieder ein
> 24/7-Verbraucher, den man nicht sinnvoll abschalten kann. Bei den
abgeschaltet.
> eingebauten Skystars schließt man einfach das Device, wenn es nichts zu
> tun gibt, und die schalten das LNB nebst Multiswitch ab.
Modulen steckt. Und jede Wohnung via SCR 4 Slots bekommt. "Etwas"
abschalten wäre da nur nachts drin wenn NIEMAND TV/Radio nutzte. Wobei
noch offen bliebe ob der LNB auch strom spart wenn alle TR in Standby
wären. Versorgt werden sie dennoch - aber immerhin vom Allgemeinstrom.
>>> Also doch Hardware.
>>
>> Die der Onboard-NIC ja. So scheint es.
>
> Oder die Verbindung derselben. Mglw. die Buchse oder eine Lötstelle
> derselben.
bombenfest steckt. Allerdings hat die Onboard-NIC vorher (Vor dem
Neu-Flashen der Firmware) auch gerne mal den Abraster gemacht. Sprich:
Trotz kabel drin und normalem Start einfach nicht aktiviert und auch
nicht nachträglich. Erst stromlos machen und eine Weile Warten und dann
gern mal etliches Drücken des Reset-Tasters hat die dann reaktiviert.
Davor war der auch gern mal aus und wollte sich nicht per Taster
einschalten lassen, sprang aber bei Stromzufuhr kurz an um wieder aus zu
bleiben.
Das alles ist sein dem FW-ReFlash nicht mehr aufgetreten. Das scheint
echt was gebracht zu haben. Nur die "AE Not Found ... " acpi-meldungen
beim boot gehen nicht weg. Dem Fehlen also offenbar immer noch
ACPI-Infos zu <irgendwas>
Könnte also IMO am ehesten ein Sporadischer Fehler der NIC sein, Buchse,
Lötstelle, tja.
> Aber ich denke Samba ist jetzt wirklich entlastet.
Kay
0 new messages