UGOS Pro 1.19.1.0126 / 1.19.10.0022 – Firmware-Update (Changelog & Infos)

Fortsetzung zum Verlust der LED Helligkeit im Ruhezustand, siehe Post #128

Das Problem wandert. Ich hatte es nun einzeln bei den LEDs 3, 4 und 5.
Ich habe vom Support Terminal Befehle bekommen, die ich bei erneuten auftreten eingeben soll.

Quote

Hallo,

könnten Sie sich per SSH am NAS anmelden, wenn das Problem erneut auftritt, und die folgenden Befehle ausführen?

1. LED-Status abfragen:
cat /sys/class/leds/diskX/state

Zum Beispiel:

cat /sys/class/leds/disk1/state

cat /sys/class/leds/disk2/state

Stellen Sie anschließend die Helligkeit der entsprechenden LED manuell ein und beobachten Sie, ob sie heller wird:
echo 255 > /sys/class/leds/diskX/brightness
echo 255 > /sys/class/leds/disk1/brightness
echo 255 > /sys/class/leds/disk2/brightness

Bitte beobachten Sie, ob die Helligkeit von disk4 bei manueller Einstellung der LED-Helligkeit mit der Helligkeit der anderen
Disk-LEDs übereinstimmt.

Mit freundlichen Grüßen

Display More

Jetzt ist das Problem zwar gerade nicht da, aber ich mal die Befehle durchgespielt.

LED-Status abfragen, Terminal Befehl: cat /sys/class/leds/disk1/state

Ergebnis bei Einstellung in der Systemsteuerung -> Hardware & Energie -> LED Anzeige: 0% Helligkeit:
op_mode:on,brightness:0,color:255:255:255,t-hight:2000, t-low:1000,mode:0x3

Ergebnis bei Einstellung in der Systemsteuerung -> Hardware & Energie -> LED Anzeige: 25% Helligkeit:
op_mode:on,brightness:63,color:255:255:255,t-hight:2000, t-low:1000,mode:0x3

Ergebnis bei Einstellung in der Systemsteuerung -> Hardware & Energie -> LED Anzeige: 50% Helligkeit:
op_mode:on,brightness:127,color:255:255:255,t-hight:2000, t-low:1000,mode:0x3

Ergebnis bei Einstellung in der Systemsteuerung -> Hardware & Energie -> LED Anzeige: 75% Helligkeit:
op_mode:on,brightness:191,color:255:255:255,t-hight:2000, t-low:1000,mode:0x3

Ergebnis bei Einstellung in der Systemsteuerung -> Hardware & Energie -> LED Anzeige: 100% Helligkeit:
op_mode:on,brightness:255,color:255:255:255,t-hight:2000, t-low:1000,mode:0x3

Manuelle Einstellung:

Zur besseren Wahrnehmung beim Testen der manuellen Einstellung habe ich die Helligkeit zunächst auf 0% eingestellt.

Einstellung in der Systemsteuerung -> Hardware & Energie -> LED Anzeige: 0% Helligkeit:
LED-Status abfragen, Terminal Befehl: cat /sys/class/leds/disk1/state
op_mode:on,brightness:0,color:255:255:255,t-hight:2000, t-low:1000,mode:0x3
Ergebnis wie oben.

Manuelle Einstellung (root Rechte erforderlich) auf 100% Helligkeit
LED-Helligkeit manuell einstellen auf 255, Terminal Befehl: echo 255 > /sys/class/leds/disk1/brightness

Optisches Ergebnis: Die LED 1 leuchtet direkt einmalig für ca. 1 Sekunde mit 100% Helligkeit auf. Das wars.

Erneut LED-Status abfragen, Terminal Befehl: cat /sys/class/leds/disk1/state
Ergebnis aus dem Terminal: op_mode:on,brightness:255,color:255:255:255,t-hight:2000, t-low:1000,mode:0x3

Obwohl die Helligkeit nun mit 255 (= 100% Helligkeit) ausgelesen wird, fällt die LED 1 nach dem einmaligen 100% Aufleiten wieder auf 0% Helligkeit zurück. Das Ganze verhält sich bei den anderen LEDs und bei anderen Helligkeits-Einstellung in der Systemsteuerung genauso.

Zurücksetzen nach dem Testen erfolgt am besten durch erneute Einstellung in
Systemsteuerung -> Hardware & Energie -> LED Anzeige auf die gewünschte Helligkeit.

Die manuelle Einstellung müsste doch persistent sein - oder liege ich hier einem Irrtum auf?

Ich warte besser noch bis das Problem erneut auftritt, dann gehe ich wieder auf den Support zu.

Fortsetzung folgt.

Da war ja noch was.
Ich hatte zur Firmware 1.17.0.0094 ein Ticket "Geplantes Ein-/Ausschalten bei IDX 6011 PRO" aufgemacht.
Link:
https://ugreen-forum.de/forum/thread/2954-ugos-pro-1-17-0-0094-1-17-0-0095-firmware-update-changelog-infos/?postID=40286&highlight=H%25C3%25A4ufigkeit#post40286

Das Problem wurde mit der Firmware 1.19.10.0022 behoben.

Das Ticket ist wohl noch nicht geschlossen.
Ist meine Rückmeldung erforderlich?
Wer schließt das Ticket?

Was ist der Model Manager? Was kann man da machen. Ja ich habe noch 1.19

Quote from v4percloud

Was ist der Model Manager?

Zum LLMs/KI hosten.

Alle Probleme mit FW Update 1.20. behoben. Alles wieder da.

Brauchnix also bisher habe tatsächlich ich immer die Tickets geschlossen. Ob sie das machen, kann ich nicht sagen

Quote from Simon2310

Brauchnix also bisher habe tatsächlich ich immer die Tickets geschlossen. Ob sie das machen, kann ich nicht sagen

Danke für die Info, selber schließen geht also.

Ich habe dem Support mitgeteilt, das das Problem behoben ist und auch gefragt wer das Ticket schließt.

Hier die Antwort vom Support:

Quote

Hallo,
vielen Dank für die Rückmeldung, dass das Problem behoben wurde.
Wie von Ihnen bestätigt, werden wir diesen Fall nun schließen.
Sollten Sie weitere Probleme mit unserem NAS-Produkt haben, können Sie sich jederzeit gerne an uns wenden - wir helfen Ihnen
gerne weiter.
Mit freundlichen Grüßen

In meinem Fall wurde das Ticket Support durch den geschlossen.

Fortsetzung zum Verlust der LED Helligkeit im Ruhezustand, Post #162

Das Problem mit der Helligkeit der DISK-Leds ist heute wieder mehrfach aufgetreten.
Es ist bisher fallweise an verschiedenen DISK-Leds vorgekommen: 3, 4, 5, 5+6, 6

Voreinstellung:
Einstellung in der Systemsteuerung -> Hardware & Energie -> LED Anzeige: 50% Helligkeit.
Der Fehler ist bei mir auch mit 25% Helligkeit aufgetreten. Vermutlich spielt die eingestellte Helligkeit keine Rolle.

Abfrage LED-Status von DISK-LED 4 im Normalfall (Helligkeit 50%)
Teminal Eingabe: cat /sys/class/leds/disk4/state
Teminal Ausgabe: op_mode:on,brightness:127,color:255:255:255,t-hight:2000, t-low:1000,mode:0x3

Ich habe die Anleitung vom Support durchgespielt und am Beispiel DISK-LED 4 dokumentiert.
Bei allen anderen fallweise betroffenen DISK-Leds kamen die gleichen Ergebnisse heraus.

1. Abfrage des LED-Status von DISK-LED 4 im Fehlerfall (Helligkeit geschätzt 10%)
Teminal Eingabe: cat /sys/class/leds/disk4/state
Teminal Ausgabe: op_mode:off,brightness:0,color:255:255:255,t-hight:2000, t-low:1000,mode:0x0

2. Manuelle Einstellung von DISK-LED 4 auf die Helligkeit von 50%
Terminal Eingabe (root Rechte): echo 127 > /sys/class/leds/disk4/brightness

Ergebnis: Die DISK-LED 4 hat sofort wieder im korrekten Rhythmus und mit korrekten Helligkeit von 50% geblinkt.

3. Abfrage des LED-Status von DISK-LED 4 nach der manuellen Einstellung auf die Helligkeit von 50%
Teminal Eingabe: cat /sys/class/leds/disk4/state
Teminal Ausgabe: op_mode:on,brightness:127,color:255:255:255,t-hight:2000, t-low:1000,mode:0x3

Ergebnis: Der LED-Status von DISK-LED 4 entspricht wieder dem Normalfall, siehe oben.

Die Information habe ich an den Support weitergeleitet.
Auf die Rückmeldung bin ich gespannt.

Danke dass Du uns so ausführlich auf dem laufenden hälst! Wer weiß wer später von Deinen Erfahrungen profitieren kann. Auch wenn ich im Augenblick nichts produktives beitragen kann lese ich doch gern mit.

Fortsetzung zu: Bei der Suche in Volume 3 wird das schlafende Volume 2 aufgeweckt. Post #121 / #142

Ich habe dazu ein Ticket aufgemacht und den Suppert nach dem Grund gefragt, warum die Suchdatenbank der App „Dateien“ auf Volume 2 liegt.

Mein Ticket:

Quote

Bei der Suche im Suchfeld in der App „Dateien“ in Volume 1 oder Volume 3 wird das schlafende Volume 2 aufgeweckt.

IDX6011PRO mit UGOS Pro 1.19.10.0022 App „Dateien“ Version 1.17.20.0045
Voreinstellung: Systemsteuerung -> Energie -> Festplatten-Ruhezustand -> Bei Bedarf

Beispiel bei Suche in Volume 3 (reproduzierbar):
1. In der App „Dateien“ ist in Volume 3 ein beliebiger Ordner / Unterordner geöffnet
2. Volume 2 schläft (muss erfüllt sein, sonst ist der Effekt nicht sichtbar)
2. In das Suchfeld der App „Dateien“ wird etwas beliebiges zur Suche eingegeben (Treffer oder kein Treffer spielt keine Rolle)
Ergebnis: Volume 2 wird sofort nach der Eingabe in das Suchfeld der App „Dateien“ vom System gestartet.

Das lässt vermuten, das UGOS bzw. die „App Dateien“ die Ergebnisse der Suche (auch wenn nichts gefunden wird) in eine separate
Datenbank schreibt oder dort sucht.

Das bedeutet auch, das die Datenbank der App „Dateien“ demnach auf Volume 2 liegt.

Beim Einrichten des NAS wird immer zuerst Volume 1 angelegt. Dort hatte ich diese Datenbank vermutet.

Können Sie mir bitte den Grund mitteilen, warum diese Datenbank auf Volume 2 liegt bzw. verlegt wurde.
Mit freundlichen Grüßen

Display More

Die Rückmeldung vom Support kam in englischer Sprache zurück. Das ist für mich neu.
Es gibt keine Antworten aber neuen Fragen vom Support. Der Support will jetzt wohl selber untersuchen, auf welchem Volume diese Datenbank liegt. Ich habe eine Anleitung für weitere Terminal Befehle vom Support erhalten. Hier die Antwort:

Quote

Hello,

Before determining whether the Files search database is located on Volume 2, we would first like to confirm that the wake-up is
specifically triggered by the Files search and not by another background service.

Could you first let us know how you are determining that Volume 2 has been activated? For example, are you seeing its status
change from sleep/standby to active in UGOS, observing the HDD LED, or hearing the drive spin up?

For the test, please temporarily pause any user-configured services that may access Volume 2, such as Docker containers, virtual
machines, Backup & Sync tasks, download tasks, or media/photo indexing tasks. There is no need to uninstall anything or stop UG
OS system services.

After Volume 2 has entered HDD sleep again, please connect to the NAS via SSH and run:

"`bash
Isblk -o NAME,SIZE,MODEL,SERIAL,MOUNTPOINTS

This will allow us to identify which physical disk belongs to Volume 2.

Once identified, please keep the NAS otherwise idle and reproduce the issue by performing only a search in the Files app.

If possible, you can also monitor disk I/O at the same time with:

"`bash

iostat -dx 1

or, if available:

"'bash

sudo iotop -oPa

We would like to confirm whether Volume 2 changes from standby to active exactly when the Files search is performed,
and whether any specific process generates I/O on that disk at the same time.

This will allow us to distinguish a Files/search-related disk access from unrelated background activity before investigating
where the search/index data is stored.

Display More

Also langweilig wird es mir wohl erstmal nicht.

Fortsetzung folgt ...

Fortsetzung zum Verlust der LED Helligkeit im Ruhezustand, Post #169

Es wurde ein Bug Report erstellt, das Ticket an die Entwicklung weitergeleitet:

Quote

Sehr geehrter Kunde,

vielen Dank nochmals für Ihre ausführlichen Tests.

Wir haben die Diagnoseinformationen zusammen mit den von Ihnen bereitgestellten LED-Statuswerten geprüft.
Derzeit ergeben sich folgende Erkenntnisse:

- Die betroffenen Disk-LEDs sind nicht auf einen bestimmten Festplattenslot beschränkt, und das Problem tritt hauptsächlich auf,
nachdem die HDDs in den Standby-/Ruhezustand gewechselt sind.
- Wenn das Problem auftritt, ändert sich der LED-Status vom normalen Zustand
'op_mode:on, brightness:127, mode:0x3' zu `op_mode:off, brightness:0, mode:0x0'.
- Nachdem der Helligkeitswert manuell erneut gesetzt wird, kehrt die betroffene LED sofort zur korrekten Helligkeit und zum normal
en Blinkverhalten zurück.
- Der LED-Controller bzw. LED-Treiber wird laut Protokoll normal initialisiert, und wir konnten keinen eindeutigen
Kommunikationsfehler mit dem LED-Controller während des Betriebs feststellen.

Wir haben daher einen Bug Report erstellt und die Diagnoseinformationen, Ihre Testergebnisse sowie die Fotos und das Video an
unser Entwicklungsteam zur weiteren Analyse weitergeleitet.

Bitte lassen Sie die aktuelle Konfiguration nach Möglichkeit unverändert. Sobald wir eine weitere Rückmeldung vom
Entwicklungsteam erhalten, informieren wir Sie über dieses Ticket.

Vielen Dank für Ihre ausführliche Unterstützung und Mitarbeit.

Mit freundlichen Grüßen

Display More

Ich warte nun auf eine Rückmeldung vom Entwicklungsteam.
Fortsetzung folgt...

Ich weiß ja nicht, was du für ein NAS hast, aber ich würde mal die Firmware 1.20 installieren und dann weiter sehen.

Quote from charly700

Ich weiß ja nicht, was du für ein NAS hast, aber ich würde mal die Firmware 1.20 installieren und dann weiter sehen.

Eben habe ich meine Signatur mit meiner Hardware hinterlegt.
Eigentlich wollte ich das schon früher machen. Dein Post hat mich daran erinnert.

Mein NAS ist das iDX6011PRO. Es gibt leider noch keine Firmware 1.20 dafür.
Der aktuelle Stand ist die Firmware 1.19, die habe ich seit dem 11.09. auf dem NAS am Laufen.
Die Version 1.19 habe ich in der Systemsteuerung zum Update angeboten bekommen.
Im Ugreen Download-Center ist nach wie vor nur die Firmware 1.17 als neueste Version verfügbar.

Fortsetzung zu: Bei der Suche in Volume 3 wird das schlafende Volume 2 aufgeweckt. Post #171

Ich habe dem Support die gewünchten Informationen übermittelt.
Auf Rückfrage habe ich noch ein aktuelles Systemprotokoll hinterhergeschickt.
Hier der Zwischenstand, 1. Antwort:

Quote

Sehr geehrter Kunde,
vielen Dank für Ihre Rückmeldung sowie für die Bereitstellung dieser überaus detaillierten, präzisen und professionellen Diagnosed
aten (einschließlich der Ausgaben von Isblk, iostat und iotop). Dies hat uns bei der genauen Ursachenanalyse sehr geholfen.
Anhand der von Ihnen übermittelten Protokolle und Befehlsausgaben konnten wir das Systemverhalten wie folgt analysieren:
Speicherarchitektur und Festplattenzuordnung:
Gemäß der Ausgabe von Isblk stellt sich Ihre Speicheraufteilung wie folgt dar:
Volume 1: Besteht aus zwei NVMe SSDs (nvme0n1, nvme2n1 als RAID-Verbund md1), eingehängt unter /home und /volume1;
Volume 2: Besteht aus 5x 10TB Festplatten (sda, sdb, sdc, sdd, sdf als RAID-Verbund md2), eingehängt unter /volume2;
Volume 3: Besteht aus einer einzelnen 2TB Festplatte (sde als md3), eingehängt unter /volume3;
Das Basissystem sowie das Root-Dateisystem befinden sich auf der internen SSD (nvme1n1).
Analyse der Ursache für das Aufwachen der Festplatten:
In Ihrem iostat-Protokoll ist deutlich zu erkennen, dass im Moment der Sucheingabe in der App „Dateien“ eine Leseanforderung an
die zu Volume 2 (md2) gehörende Festplatte sdf gesendet wurde. Die Lese-Wartezeit (r_await) lag hierbei bei 10716.00 ms (ca. 10
,7 Sekunden):

sdf 1.00 16.00 0.00 0.00 10716.00 16.00 1.00 4.00 0.00 0.00 9.00 4.00 ... 155.20
Diese Verzögerung von rund 10 Sekunden ist das typische Merkmal für das Hochfahren (Spin-up) einer zuvor im Ruhezustand (Sp
indown) befindlichen mechanischen Festplatte, wodurch in der Folge das gesamte Volume 2-Array aufgeweckt wird.
Gleichzeitig belegt die iotop-Ausgabe die Aktivität des systeminternen Suchdienstes search_serv sowie des Dateimanager-Dienste
s filemgr_serv:

4653 be/4 root 0.00 B 584.00 K search_serv
Zur Frage, ob die Suchdatenbank auf Volume 2 liegt:
Die Suchdatenbank liegt nicht auf Volume 2. Die Programmkomponenten und Datenbankstrukturen von search_serv befinden sich
auf dem Systemspeicher (nvme1n1) und im primaren Systembereich.
Der Grund für das Aufwecken von Volume 2 liegt vielmehr darin, dass die aktuelle Suchlogik der App „Dateien“ bei der Initialisierun
g einer Suchanfrage die Einhängepunkte aller verfügbaren Speicher-Volumes (/volume1, /volume2, /volume3) abfragt bzw. deren
Metadatenstatus prüft. Selbst wenn die Suche auf einen bestimmten Ordner innerhalb von Volume 1 oder Volume 3 beschränkt ist,
führt die Vorbereitung des Suchkontextes dazu, dass auch der Mountpoint von Volume 2 berührt wird, was wiederum das Aufweck
en des Arrays md2 durch den Linux-Kernel auslöst.
Weiteres Vorgehen und Bitte um Protokolldatei:
Ihre Feststellung ist vollkommen berechtigt: Eine lokale Suche innerhalb eines bestimmten Volumes oder Unterordners sollte keine
unbeteiligten, schlafenden Speicherpools aufwecken. Um unserem Entwicklerteam (R&D) eine tiefgehende Analyse der Aufrufkett
en auf Codeebene zu ermöglichen und eine zielgerichtete Optimierung umzusetzen, benötigen wir zusätzlich ein vollständiges Dia
gnosepaket Ihres Systems.
Falls es Ihnen möglich ist, bitten wir Sie daher um die Bereitstellung eines Systemprotokolls:
Menüpfad: Hilfe-Center (Support) -> Hilfswerkzeuge (Auxiliary Tools) -> Ein-Klick-Erstellung (One-click Generation) (bitte die gener
ierte .tgz-Datei herunterladen und uns als Ticketanhang zukommen lassen).
Sobald uns die vollständigen Protokolldaten vorliegen, übergeben wir den gesamten Vorgang direkt an das Entwicklerteam, damit
die Suchbereichs-Isolierung in kommenden Updates optimiert werden kann.
Wir bedanken uns nochmals herzlich für Ihre hervorragende Zuarbeit und Ihre Unterstützung bei der Verbesserung von UGOS Pro.
Mit freundlichen Grüßen

Display More

Und weiter mit der 2. Antwort:

Quote

Hallo,

vielen Dank fur die Bereitstellung des aktuellen Systemprotokolls.

Wir haben die Protokolle geprüft und konnten das Verhalten weiter eingrenzen. Dabei ist zu erkennen, dass die von Ihnen ausgefü
hrte Suche ausschließlich auf einen Ordner innerhalb von Volume 3 beschränkt war. Während der Initialisierung dieser Suche greift
der interne Suchdienst jedoch auf eine temporäre Datenbank für Suchergebnisse unter folgendem Pfad auf Volume 2 zu:

/volume2/@search/title_search_result/ ...

Dieser Zugriff steht zeitlich mit dem Aufwachen der zu Volume 2 gehorenden Festplatten in Zusammenhang und erklart, warum Vol
ume 2 auch dann aktiviert wird, wenn die eigentliche Suche auf Volume 3 beschränkt ist.

Zur Präzisierung unserer vorherigen Rückmeldung: Dies bedeutet nicht zwangsläufig, dass die gesamte Suchdatenbank auf Volum
e 2 gespeichert ist. Die Protokolle zeigen jedoch, dass zumindest eine temporäre Datenbank für Suchergebnisse dort verwendet b
zw. angesprochen wird.

Da nun geklärt ist, welcher interne Zugriff das Aufwachen von Volume 2 auslöst, werden wir die Protokolle und die entsprechenden
Informationen an unser Entwicklungsteam zur weiteren Prüfung weiterleiten. Dort muss insbesondere geklärt werden, warum für di
ese temporäre Suchdatenbank Volume 2 verwendet wird und ob dieses Verhalten angepasst werden kann, sodass ein nicht beteili
gtes, schlafendes Volume nicht unnötig aufgeweckt wird.

Von Ihrer Seite sind derzeit keine weiteren Tests erforderlich. Sobald uns eine Rückmeldung des Entwicklungsteams vorliegt, werd
en wir Sie uber dieses Ticket informieren.

Vielen Dank nochmals für Ihre ausführlichen Tests und Ihre Unterstützung bei der Analyse.

Mit freundlichen Grüßen

Display More

In der 2. Antwort wird präzisiert das eine temporäre Suchdatenbank auf Volume 2 liegt.
Auch dieses Ticket wird an das Entwicklungsteam durchgereicht.

In Bezug auf die Antwort vom Support fällt mir ein weiteres noch offenes Ticket von mir ein:
Halbes Volume 2 wird aufgeweckt, der Rest pennt einfach weiter. Post #129
Je nach Antwort wird zu gegebener Zeit wird diese Frage nachgereicht:
Aus welchem Grund liegt die Datenbank für die Systemdiagnoseinformationen auf Disk 1, 2, 3 (ein Teil vom Raid 5 Verbund aus Disk 1, 2, 3, 4, 5 von Volume 2)?

Brauchnix es wäre schön, wenn Du statt Bilder Text als Zitat hineinkopierst. Die Information ist zwar die gleiche, aber wenn man später mal die Boardsuche benutzt um etwas zu finden, dann bekommt man kein Ergebnis, da Bilder ja nicht durchsuchbar sind. Damit wären Deine guten Informationen für immer im Nirvana verschwunden.

Quote from steffenglock

Brauchnix es wäre schön, wenn Du statt Bilder Text als Zitat hineinkopierst. Die Information ist zwar die gleiche, aber wenn man später mal die Boardsuche benutzt um etwas zu finden, dann bekommt man kein Ergebnis, da Bilder ja nicht durchsuchbar sind. Damit wären Deine guten Informationen für immer im Nirvana verschwunden.

Oh ja, natürlich. Das macht absolut Sinn.

Die Antworten aus dem Ticket hatte ich mit dem Snipping Tool ausgeschnitten.
Mit dem Snipping Tool kann man ja auch in Text umwandeln, stimmt.

Ich werde meine Posts überarbeiten.

Erledigt. Ich habe meine Posts bearbeitet und habe die Screenshots in Zitate mit Textinhalt ausgetauscht.
Und danke für den Hinweis. Vollzitate werde ich künftig soweit möglich vermeiden.

Antwort vom Support zu „Halbes Volume 2 wird aufgeweckt, der Rest pennt einfach weiter“, Post #129
Hier ist die Antwort vom Support:

Quote

Sehr geehrter Nutzer,

vielen Dank für Ihre Geduld.

Wir haben den Fall intern mit dem Entwicklungsteam geprüft. Nach der aktuellen Rückmeldung handelt es sich bei dem
beschriebenen Verhalten um ein normales Verhalten und es hat keine Auswirkungen auf die Datenintegrität.

Bei einem RAID-5-Verbund bedeutet ein Zugriff nicht zwingend, dass immer alle Festplatten gleichzeitig aufgeweckt werden
müssen. Je nach konkretem Lese- oder Schreibzugriff können nur die jeweils benötigten Daten- bzw. Paritätsblöcke betroffen sein. Daher kann es kurzfristig vorkommen, dass nur ein Teil der Festplatten aktiv wird, während andere Festplatten weiterhin im Ruhemodus bleiben.

Da die Paritätsblöcke bei RAID 5 über die Festplatten verteilt sind, sollten sich die Zugriffe und Aufwachvorgänge bei längerer
und gleichmäßiger Nutzung insgesamt ausgleichen. Dass in Ihrem beobachteten Szenario vorübergehend drei Festplatten aktiv
sind und zwei weiterhin ruhen, ist daher nachvollziehbar und stellt keinen Hinweis auf einen Fehler des RAID-Verbunds oder ein
Datenrisiko dar.

Mit freundlichen Grüßen

UGREEN Technical Support

Display More

Dann kann das Verhalten bei Systemzugriffen wohl so richtig sein.