NAS schreibt seit Tagen

[maxi_mus]

Ich habe ein DS416play. Ich habe letzte Woche ca. 1 TB an Daten gelöscht (über 100'000 Files). Mittlerweile sind die HDDs seit über 4 Tagen konstant am schreiben. Nicht nur, dass mich das Geräusch zum Wahnsinn treibt, aber das Gerät ist natürlich derweil unbrauchbar, weil extrem langsam.

Deshalb meine Fragen: Ist es normal, dass dies so lange dauert? Und, falls nicht: Was kann ich machen, um allfällige Leerlauf-Prozesse zu killen?

 

[Benie]

Ja, das kann durchweg normal sein. Die DS416Play ist kein Rennpferd und bei 1GB RAM da wird doch einiges geswapt werden zudem die CPU dann wohl auch auf Anschlag arbeiten wird.
Es muß ja nicht nur die Bilder gelöscht werden sondern auch das Raid mehr oder weniger neu geschrieben werden. Neu indexiert wird dabei auch noch.
Bevor Du jetzt versuchst irgendwas zu beschleunigen, warte lieber das sichere Ende der Aktion ab.

 

[w00dcu11er]

Die Restzeit, die dir noch verbleibt, ist definitiv kürzer als jene, die du für einen "neuen" Versuch benötigen würdest. Kennen wir alle schon. Ist irgend ein Effekt (müsste schon dafür einen Namen geben ^^).
Also, ich würde auch dazu raten, einfach das Ganze abzusitzen.

 

[maxi_mus]

OK, danke. Kann ich das Gerät aber am Abend runterfahren, oder unterbricht das den ganzen Prozess?

 

[Thorfinn]

OK, danke. Kann ich das Gerät aber am Abend runterfahren, oder unterbricht das den ganzen Prozess?

Du kannst das runterfahren und selber in aller Ruhe schlafen. Dann neu starten. Irgendwann meint sie dann es wäre Zeit das Raid neu zu sortieren und indexiert von vorne.
Bei mir verschwand die DS214play weil sie sich zu viel mit sich selbst beschäftigt hat. Bei den alten *play sind viele Funktionen "proof of concept", richtig produktiv einzusetzen war sie bei mir schon ab 1 user nicht.

 

[maxi_mus]

Ich nehm das jetzt mal als 'besser nicht'

 

[Benares]

Hast du mal geschaut, was da alles, z.B. in den letzten 5 Minuten geschrieben wurde?
Ich benutze dazu gerne die Befehle

find /volume1 -cmin -5

(Datenpool auf Platte), oder

find / -mount -cmin -5

(Systembereich)

 

[maxi_mus]

Die Liste sieht in ungefähr so aus:
/volume1/@database/pgsql/base/16385/16646
/volume1/@database/pgsql/base/16385/16647
/volume1/@database/pgsql/base/16385/16648
/volume1/@database/pgsql/base/16385/16463_vm
/volume1/@database/pgsql/base/16385/16463_fsm
/volume1/@database/pgsql/base/16385/16545_fsm
/volume1/@database/pgsql/base/16385/16609_fsm
/volume1/@database/pgsql/base/16385/16573_fsm
/volume1/@database/pgsql/base/16385/16591_fsm
/volume1/@database/pgsql/base/16385/16388_fsm
/volume1/@database/pgsql/base/16385/16388_vm
/volume1/@database/pgsql/base/16385/16573_vm
/volume1/@database/pgsql/base/16385/16591_vm
/volume1/@database/pgsql/base/16385/16609_vm

Würde es Sinn machen die Synology mit einem besseren Modell zu ersetzen? Die Festplatten kann ich ja gut noch behalten, nehm ich an. (Es sind 4x Western Digital Red 8TB NAS SATA)

 

[ctrlaltdelete]

Gab es von den 8 TB HDDs SMR?

 

[Benie]

Ich denke nur bis max 6TB gibt es das, wenn nicht sogar nur bis 4TB

 

[ctrlaltdelete]

Stimmt, gabs nur bis 6 TB!
Die DS schreibt/liest halt Vollgas in der Datenbank anscheinend.

 

[Benie]

Jip, das mit der Datenbank habe ich mir auch gedacht, hab mich nur gefragt wo die wohl dazu gehört.
Hier noch was füs Wissen, habe ich erst suchen Müssen. Ist allerdings mitlerweile etwas älter.

 

[plang.pl]

Wird Indexing in Zusammenhang mit Photos / Drive oder sowas sein

Würde es Sinn machen die Synology mit einem besseren Modell zu ersetzen?

Wenn du regelmäßig so große Datenmengen veränderst und dir das zu lange dauert, dann ja. Wenn nicht, kann man ja evtl auch damit leben, dass das eben länger dauert, wenn man es nicht alle Tage macht

 

[ctrlaltdelete]

Ich denke der Aufstellort des NAS ist hier das Problem.

 

[maxi_mus]

Wird Indexing in Zusammenhang mit Photos / Drive oder sowas sein

Wenn du regelmäßig so große Datenmengen veränderst und dir das zu lange dauert, dann ja. Wenn nicht, kann man ja evtl auch damit leben, dass das eben länger dauert, wenn man es nicht alle Tage macht

Nein nein, das ist ungewöhnlich. Es war ein Backup von einem Laptop, der 100'000 Musikfiles drauf hatte. Ich finds nur krass, dass das Löschen von Files eine solche Kopiererei auslöst...

 

[plang.pl]

Auf einem Server ist ein simples Löschen eben nicht nur ein Löschen, sondern zieht diverse "Konsequenzen" nach sich. In allen installierten Diensten dürfen die gelöschten Daten mehr gelistet sein. An allen Clients, die per Drive angebunden sind, muss die Datei gelöscht werden usw.
Wenn du also kein Drive, kein Photos, keine AudioStation und nix drauf hast, was die Dateien in irgendeiner Form indiziert, dann wäre das Löschen auch tatsächlich nur ein Löschen. Also nur auf Indizierung bezogen. Defragmentierung, RAID-Sync, btrfs-Checksums + Snapshots, Änderungsprotokolle und Speicherplatzrückgewinnung mal außen vor gelassen.

 

[Benares]

/volume1/@database/pgsql/base/16385 scheint auf jeden Fall mal was mit Postgres zu sein. Evtl. läuft da irgendwas Amok? Stop doch bitte alle Container und starte sie langsam, nacheinander neu. Oder schau einfach mal im Container Manager, welcher Container da am meisten CPU zieht.

 

[plang.pl]

Das ist die native Postgres von DSM
Wenn man da nicht manuell nen Container angebunden hat, dürfte das Photos oder irgendsowas sein

EDIT: Die 416play kann doch gar kein Docker, oder?

 

[Benares]

Echt? Bei mir herrscht dort ziemliche Ruhe. Ich sehe da nix, was da groß zappelt.

 

[Benie]

Die 416play kann doch gar kein Docker, oder?

Nein kann sie eigentlich nicht, aber es gab mal den Workaround, jedenfalls unter DSM 6.x, daß wenn man Docker manuell installiert hat, docker auch nutzen konnte.