Server beschäftigt nach Löschen

Probleme mit Samba, NFS, FTP und Co.
sprint
Beiträge: 43
Registriert: 12.10.2020 12:08:16

Server beschäftigt nach Löschen

Beitrag von sprint » 21.11.2022 14:50:51

Hallo zusammen,

ich habe mir vor zwei Jahren aus einem alten Windows Rechner (4GB RAM, 3GHz i3) einen Fileserver für daheim aufgebaut. Darin sind zwei gespiegelte 4TB Platten, zu einem ZFS Pool zusammengefaßt. Der ist in zwei virtuelle Laufwerke aufgeteilt. Ein Laufwerk hauptsächlich für Bilder und Textdateien, das andere für Filme und Musik. Das ganze wird über Openmediavault verwaltet. Betriebssystem ist Debian 10.

Auf dem zweiten Laufwerk ist ein miniDLNA Server Plugin aktiviert, damit der Fernseher direkt auf die Filme zugreifen kann. Das funktioniert auch wunderbar.

Nun ist mir aber neulich aufgefallen, daß der Server immer ewig braucht, bis er das Laufwerk wieder reorganisiert(?) hat. D.H. ich lösche drei Filme und anschließend war er ca. 20 - 30 Minuten beschäftigt. Die Platten waren ununterbrochen in Benutzung, die Kontrolllampe hat nicht einmal geflackert. Und während dieser zeit war ein Zugriff vom Fernseher auf eine andere Datei zwar möglich, aber nach spätestens 5 Sekunden gab er eine Unterbrechung.

Wenn ich den DLNA Server deaktiviere, halbierte sich zwar die Zeit ungefähr, aber auch 10 Minuten sind für das Löschen von drei Dateien viel zu viel.Ich hatte dann den Tip bekommen, den "notify_interval" Wert von 60 auf 900 Sekunden raufzusetzen. Das hat die Löschzeiten zwar auch ca. um die Hälfte verkürzt, aber wirklich befriedigend ist das ganze nicht.

Der eigentliche Zugriff auf den Server geschieht über ein Macbook. Um da eine eventuellen Zusammenhang auszuschließen, habe ich auch mal ein paar Dateien direkt über die Konsole gelöscht. Der Effekt war der selbe. 20 Minuten rödeln.

Merkwürdig ist auch, daß ich auf dem anderen virtuellen Laufwerk machen kann, was ich will. Ich lösche fünfhundert Dateien und wenn die letzte weg ist, ist auch der Server wieder ruhig.

Hat jemand eine Idee, woran das liegen könnte? Ist das der DLNA Server oder kann das an der Hardware liegen? Der Rechner ist zwar nicht der neueste, aber nach den OMV Informationen sind weder Speicher, noch Prozessor währenddessen jemals zu 100 % ausgelastet. Und ist das auch eine Hardwaresache, daß ein Film immer wieder mal unterbricht, wenn ich mit dem Rechner auf das andere Laufwerk zugreife?

Benutzeravatar
debilian
Beiträge: 1162
Registriert: 21.05.2004 14:03:04
Wohnort: 192.168.43.7
Kontaktdaten:

Re: Server beschäftigt nach Löschen

Beitrag von debilian » 21.11.2022 15:26:44

Festplatten checken, was macht die "wa" oben in "top" auf der Konsole beim Löschen?

gruss
-- nichts bewegt Sie wie ein GNU --

sprint
Beiträge: 43
Registriert: 12.10.2020 12:08:16

Re: Server beschäftigt nach Löschen

Beitrag von sprint » 21.11.2022 15:39:03

debilian hat geschrieben: ↑ zum Beitrag ↑
21.11.2022 15:26:44
Festplatten checken, was macht die "wa" oben in "top" auf der Konsole beim Löschen?

gruss
Kannst du das auch für Dummies ausdrücken? Ich weiß beim besten Willen nicht, was du meinst.

Benutzeravatar
Tintom
Moderator
Beiträge: 3029
Registriert: 14.04.2006 20:55:15
Wohnort: Göttingen

Re: Server beschäftigt nach Löschen

Beitrag von Tintom » 21.11.2022 17:41:15

Damit war wohl gemeint, dass du während des Löschens ein Terminal öffnen sollst, darin den Befehl top eingibst und den Wert 'wa' (Abkürzung für waiting) ablesen sollst.
Sollte ungefähr so aussehen (Hervorhebung von mir):

top - 17:39:51 up 9:24, 1 user, load average: 0,16, 0,14, 0,25
Tasks: 235 total, 1 running, 234 sleeping, 0 stopped, 0 zombie
%Cpu(s): 8,6 us, 5,7 sy, 0,0 ni, 85,7 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
MiB Mem : 3840,9 total, 290,7 free, 2161,9 used, 1388,3 buff/cache
MiB Swap: 960,2 total, 718,6 free, 241,6 used. 1172,6 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

Benutzeravatar
debilian
Beiträge: 1162
Registriert: 21.05.2004 14:03:04
Wohnort: 192.168.43.7
Kontaktdaten:

Re: Server beschäftigt nach Löschen

Beitrag von debilian » 21.11.2022 19:12:54

danke dir, Tintom....
-- nichts bewegt Sie wie ein GNU --

Benutzeravatar
bluestar
Beiträge: 2334
Registriert: 26.10.2004 11:16:34
Wohnort: Rhein-Main-Gebiet

Re: Server beschäftigt nach Löschen

Beitrag von bluestar » 21.11.2022 20:34:00

sprint hat geschrieben: ↑ zum Beitrag ↑
21.11.2022 14:50:51
Hallo zusammen,

ich habe mir vor zwei Jahren aus einem alten Windows Rechner (4GB RAM, 3GHz i3) einen Fileserver für daheim aufgebaut. Darin sind zwei gespiegelte 4TB Platten, zu einem ZFS Pool zusammengefaßt.
Du bist was den RAM sehr sehr knapp aufgestellt, bei 4TB Poolgröße benötigt ZFS deine 4GB RAM komplett.

sprint
Beiträge: 43
Registriert: 12.10.2020 12:08:16

Re: Server beschäftigt nach Löschen

Beitrag von sprint » 21.11.2022 21:40:44

Damit war wohl gemeint, dass du während des Löschens ein Terminal öffnen sollst, darin den Befehl top eingibst und den Wert 'wa' (Abkürzung für waiting) ablesen sollst.
Danke für die Erklärung.

Ich habe mal einige Dateien gelöscht und in der busy Phase anschließend diese Werte erhalten:

top - 20:36:16 up 1 day, 23:29, 1 user, load average: 92,81, 34,09, 12,87
Tasks: 414 total, 1 running, 413 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0,0 us, 0,5 sy, 0,0 ni, 0,0 id, 99,4 wa, 0,0 hi, 0,1 si, 0,0 st
MiB Mem : 3920,2 total, 777,0 free, 2725,4 used, 417,9 buff/cache
MiB Swap: 4086,0 total, 4083,0 free, 3,0 used. 919,0 avail Mem
Du bist was den RAM sehr sehr knapp aufgestellt, bei 4TB Poolgröße benötigt ZFS deine 4GB RAM komplett
Und ich dachte immer, Linux wäre so genügsam :wink:

Wenn das so ist, sollte ich das RAM wohl verdoppeln.

Benutzeravatar
schorsch_76
Beiträge: 2535
Registriert: 06.11.2007 16:00:42
Lizenz eigener Beiträge: MIT Lizenz

Re: Server beschäftigt nach Löschen

Beitrag von schorsch_76 » 22.11.2022 06:33:57

sprint hat geschrieben: ↑ zum Beitrag ↑
21.11.2022 21:40:44
Damit war wohl gemeint, dass du während des Löschens ein Terminal öffnen sollst, darin den Befehl top eingibst und den Wert 'wa' (Abkürzung für waiting) ablesen sollst.
Danke für die Erklärung.

Ich habe mal einige Dateien gelöscht und in der busy Phase anschließend diese Werte erhalten:

top - 20:36:16 up 1 day, 23:29, 1 user, load average: 92,81, 34,09, 12,87
Tasks: 414 total, 1 running, 413 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0,0 us, 0,5 sy, 0,0 ni, 0,0 id, 99,4 wa, 0,0 hi, 0,1 si, 0,0 st
MiB Mem : 3920,2 total, 777,0 free, 2725,4 used, 417,9 buff/cache
MiB Swap: 4086,0 total, 4083,0 free, 3,0 used. 919,0 avail Mem
Du bist was den RAM sehr sehr knapp aufgestellt, bei 4TB Poolgröße benötigt ZFS deine 4GB RAM komplett
Und ich dachte immer, Linux wäre so genügsam :wink:

Wenn das so ist, sollte ich das RAM wohl verdoppeln.
Vergleich das mak wenn du auf der anderen Platte was löschen tust...
Zur Genügsamkeit: zfs nutzt einen Arc Cache. Das ist das Herz von zfs. Das braucht viel RAM. Zfs ist nicht Mainline. Damit ist es nicht "Linux" ;)

Der hohe iowait kann auch auf eine defekte Platte hindeuten wenn die andere baugleiche Platte keine Probleme hat...

Schau dir mal Debianiotop an wenn du was löschen tust. Das zeigt welche Prozesse das auslösen.

Code: Alles auswählen

sudo iotop
https://openzfs.github.io/openzfs-docs/ ... iderations

sprint
Beiträge: 43
Registriert: 12.10.2020 12:08:16

Re: Server beschäftigt nach Löschen

Beitrag von sprint » 22.11.2022 09:05:08

Die Platten sind gerade einmal zwei Jahre alt und auch der SMART Status ist bei beiden gut.

Ich habe mir aber gestern Abend noch zwei Speicherriegel bestellt, so daß ich dann auf 8 GB komme. Mal sehen, ob das was bringt. Die sollten morgen kommen und dann kann ich berichten.

chrbr
Beiträge: 547
Registriert: 29.10.2022 15:53:26

Re: Server beschäftigt nach Löschen

Beitrag von chrbr » 22.11.2022 10:37:55

Zum ZFS ARC: Unter FreeBSD wird geraten, den ARC Speicher zu beschränken. Das geht unter Linux bestimmt auch irgendwie. Wie genau weiß ich allerdings nicht, Hier läuft Bulseye noch mit EXT4.

sprint
Beiträge: 43
Registriert: 12.10.2020 12:08:16

Re: Server beschäftigt nach Löschen

Beitrag von sprint » 22.11.2022 11:28:15

chrbr hat geschrieben: ↑ zum Beitrag ↑
22.11.2022 10:37:55
Zum ZFS ARC: Unter FreeBSD wird geraten, den ARC Speicher zu beschränken. Das geht unter Linux bestimmt auch irgendwie. Wie genau weiß ich allerdings nicht, Hier läuft Bulseye noch mit EXT4.
Danke für den Tip. Ich habe gerade mal gesucht und hab da auch einiges gefunden. Wenn morgen die Speichererweiterung kommt, werde ich das auch konfigurieren.

Benutzeravatar
schorsch_76
Beiträge: 2535
Registriert: 06.11.2007 16:00:42
Lizenz eigener Beiträge: MIT Lizenz

Re: Server beschäftigt nach Löschen

Beitrag von schorsch_76 » 22.11.2022 12:28:37

chrbr hat geschrieben: ↑ zum Beitrag ↑
22.11.2022 10:37:55
Zum ZFS ARC: Unter FreeBSD wird geraten, den ARC Speicher zu beschränken. Das geht unter Linux bestimmt auch irgendwie. Wie genau weiß ich allerdings nicht, Hier läuft Bulseye noch mit EXT4.
Am besten auf der Kernel cmdine (in meiner oben geposteten Doku)

Code: Alles auswählen

zfs.zfs_arc_max=6442450944
Mögliche Optionen zeigt

Code: Alles auswählen

sudo modinfo zfs

sprint
Beiträge: 43
Registriert: 12.10.2020 12:08:16

Re: Server beschäftigt nach Löschen

Beitrag von sprint » 24.11.2022 22:41:31

Ich habe jetzt 4GB zusätzlich drin und den hfs_arc_max auf 5 GB eingestellt. Dadurch ist die Zeit auf ca. 5 Minuten gesunken. Die top Werte haben sich aber praktisch nicht geändert.

top - 21:48:26 up 22:18, 1 user, load average: 111,60, 65,17, 27,26
Tasks: 402 total, 1 running, 401 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0,5 us, 4,6 sy, 0,0 ni, 0,0 id, 94,7 wa, 0,0 hi, 0,2 si, 0,0 st
MiB Mem : 7946,2 total, 3786,9 free, 3626,4 used, 532,9 buff/cache
MiB Swap: 4086,0 total, 4086,0 free, 0,0 used. 4054,9 avail Mem

Bei iotop sieht das die meiste Zeit so aus

Code: Alles auswählen

Total DISK READ:       428.10 K/s | Total DISK WRITE:         0.00 B/s
Current DISK READ:     524.00 K/s | Current DISK WRITE:      10.27 K/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND                                                                                    
14835 be/0 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [z_fr_iss]
14881 be/0 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [z_fr_iss]
14882 be/0 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [z_fr_iss]
14909 be/0 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [z_fr_iss]
14878 be/0 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [z_fr_iss]
14883 be/0 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [z_fr_iss]
14869 be/0 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [z_fr_iss]
14831 be/0 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [z_fr_iss]
14846 be/0 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [z_fr_iss]
14833 be/0 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [z_fr_iss]
14847 be/0 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [z_fr_iss]
14851 be/0 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [z_fr_iss]
 1749 be/0 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [z_fr_iss]
14842 be/0 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [z_fr_iss]
14872 be/0 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [z_fr_iss]
14912 be/0 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [z_fr_iss]
14894 be/0 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [z_fr_iss]
14859 be/0 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [z_fr_iss]
14854 be/0 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [z_fr_iss]
14845 be/0 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [z_fr_iss]
14904 be/0 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [z_fr_iss]
14827 be/0 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [z_fr_iss]
14911 be/0 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [z_fr_iss]
14885 be/0 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [z_fr_iss]
14837 be/0 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [z_fr_iss]
14907 be/0 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [z_fr_iss]
 1746 be/0 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [z_fr_iss]
14871 be/0 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [z_fr_iss]
14841 be/0 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [z_fr_iss]
14898 be/0 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [z_fr_iss]
 1748 be/0 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [z_fr_iss]
14848 be/0 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [z_fr_iss]
14856 be/0 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [z_fr_iss]
14829 be/0 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [z_fr_iss]
14853 be/0 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [z_fr_iss]
 2301 be/0 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [z_rd_int]
 2325 be/0 root        3.42 K/s    0.00 B/s  0.00 % 99.99 % [z_rd_int]
14892 be/0 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [z_fr_iss]
 2321 be/0 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [z_rd_int]
14828 be/0 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [z_fr_iss]
14860 be/0 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [z_fr_iss]
14855 be/0 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [z_fr_iss]
 2316 be/0 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [z_rd_int]
Zuletzt geändert von TRex am 25.11.2022 11:47:10, insgesamt 1-mal geändert.
Grund: code-Tags zwecks Formatierung eingefügt

Benutzeravatar
schorsch_76
Beiträge: 2535
Registriert: 06.11.2007 16:00:42
Lizenz eigener Beiträge: MIT Lizenz

Re: Server beschäftigt nach Löschen

Beitrag von schorsch_76 » 25.11.2022 00:02:12

Hast du evtl. viele Snapshots?

sprint
Beiträge: 43
Registriert: 12.10.2020 12:08:16

Re: Server beschäftigt nach Löschen

Beitrag von sprint » 25.11.2022 10:41:28

schorsch_76 hat geschrieben: ↑ zum Beitrag ↑
25.11.2022 00:02:12
Hast du evtl. viele Snapshots?
Nein, überhaupt nicht.

Und daß es doch an der Hardware liegt, kann nicht sein? Speicher wird ja nicht wirklich ausgenützt, wenn ich die Daten richtig verstehe. Aber Prozessor oder HDD Controller? Der Rechner ist ja doch schon einige Jahre alt. Und hier in der Firma haben wir einen Fileserver stehen, der sehr ähnlich aufgebaut ist, nur mit moderneren Komponenten, und der läuft wunderbar, ohne irgendwelche Probleme.

Benutzeravatar
bluestar
Beiträge: 2334
Registriert: 26.10.2004 11:16:34
Wohnort: Rhein-Main-Gebiet

Re: Server beschäftigt nach Löschen

Beitrag von bluestar » 25.11.2022 13:42:47

sprint hat geschrieben: ↑ zum Beitrag ↑
25.11.2022 10:41:28
Und daß es doch an der Hardware liegt, kann nicht sein? Speicher wird ja nicht wirklich ausgenützt, wenn ich die Daten richtig verstehe. Aber Prozessor oder HDD Controller?
Du könntest mal zpool status posten.

Benutzeravatar
schorsch_76
Beiträge: 2535
Registriert: 06.11.2007 16:00:42
Lizenz eigener Beiträge: MIT Lizenz

Re: Server beschäftigt nach Löschen

Beitrag von schorsch_76 » 25.11.2022 16:25:51

https://github.com/openzfs/zfs/issues/3976

Hast den PREEMPT_RT Kernel laufen?

sprint
Beiträge: 43
Registriert: 12.10.2020 12:08:16

Re: Server beschäftigt nach Löschen

Beitrag von sprint » 26.11.2022 12:05:47

Du könntest mal zpool status posten.

Code: Alles auswählen

  pool: HansRAID
 state: ONLINE
  scan: scrub repaired 0B in 1 days 05:39:03 with 0 errors on Mon Nov 14 06:03:04 2022
config:

	NAME                                 STATE     READ WRITE CKSUM
	HansRAID                             ONLINE       0     0     0
	  mirror-0                           ONLINE       0     0     0
	    ata-ST4000VN008-2DR166_ZDH82AAF  ONLINE       0     0     0
	    ata-ST4000VN008-2DR166_ZDH82A28  ONLINE       0     0     0

errors: No known data errors

  pool: TimeMachine
 state: ONLINE
  scan: scrub repaired 0B in 20:33:19 with 0 errors on Sun Nov 13 20:57:22 2022
config:

	NAME                                       STATE     READ WRITE CKSUM
	TimeMachine                                ONLINE       0     0     0
	  ata-WDC_WD10EACS-00ZJB0_WD-WCASJ1887597  ONLINE       0     0     0

errors: No known data errors
Hast den PREEMPT_RT Kernel laufen?
Nein, da läuft Debian GNU/Linux, with Linux 5.4.203-1-pve

Benutzeravatar
bluestar
Beiträge: 2334
Registriert: 26.10.2004 11:16:34
Wohnort: Rhein-Main-Gebiet

Re: Server beschäftigt nach Löschen

Beitrag von bluestar » 26.11.2022 12:45:45

Da du die ganze Platte für ZFS verwendest, kann ein Alignment-Problem auf jeden Fall ausgeschlossen werden.

Deiner Kernel-Angabe nach verwendest du Promox, laufen deine Dienste direkt auf der Hardware oder in VMs/Containern?

sprint
Beiträge: 43
Registriert: 12.10.2020 12:08:16

Re: Server beschäftigt nach Löschen

Beitrag von sprint » 27.11.2022 01:28:04

laufen deine Dienste direkt auf der Hardware oder in VMs/Containern?
Das läuft direkt auf der Hardware

jdr
Beiträge: 10
Registriert: 19.07.2020 09:39:04

Re: Server beschäftigt nach Löschen

Beitrag von jdr » 02.12.2022 17:46:08

An der Hardware liegt es aus meiner Sicht nicht. Ich habe einen wirklich nicht besonders performanten HP N54L mit via LUKS verschlüsseltem RAIDZ1 und dort konnte ich eine relativ große Datei (in dem Fall 9,x GB) praktisch sofort löschen. Dedup nutze ich nicht. Mein ARC hat nur 1 GB (10 % des Rechner-RAMs).
bluestar hat geschrieben: ↑ zum Beitrag ↑
26.11.2022 12:45:45
Da du die ganze Platte für ZFS verwendest, kann ein Alignment-Problem auf jeden Fall ausgeschlossen werden.
Ist das so? Macht der das dann automatisch richtig aufgrund der Sektorgröße? Ich habe es bei mir immer manuell eingegeben, nutze aber auch Partitionen statt ganzer Platten..

Was sagt denn:

Code: Alles auswählen

zpool get ashift
zfs get dedup
Hast du Deduplication aktiv? Könnte das vielleicht daran liegen?

Benutzeravatar
bluestar
Beiträge: 2334
Registriert: 26.10.2004 11:16:34
Wohnort: Rhein-Main-Gebiet

Re: Server beschäftigt nach Löschen

Beitrag von bluestar » 03.12.2022 12:36:27

jdr hat geschrieben: ↑ zum Beitrag ↑
02.12.2022 17:46:08
Hast du Deduplication aktiv? Könnte das vielleicht daran liegen?
Ich würde die Frage mal ergänzen und den TE bitten uns vollständige Infos zu seinem Setup zu liefern, der verwendete Kernel passt ja auch nicht direkt zu Debian Stable.

sprint
Beiträge: 43
Registriert: 12.10.2020 12:08:16

Re: Server beschäftigt nach Löschen

Beitrag von sprint » 06.12.2022 23:50:52

So, bin wieder unter den Lebenden.
zpool get ashift

Code: Alles auswählen

NAME         PROPERTY  VALUE   SOURCE
HansRAID     ashift    0       default
TimeMachine  ashift    0       default
zfs get dedup

Code: Alles auswählen

NAME         PROPERTY  VALUE          SOURCE
HansRAID     dedup     on             local
TimeMachine  dedup     off            default
Ich würde die Frage mal ergänzen und den TE bitten uns vollständige Infos zu seinem Setup zu liefern, der verwendete Kernel passt ja auch nicht direkt zu Debian Stable.
Ich habe den Server nicht direkt per Hand aufgesetzt. Dafür habe ich von Linux zu wenig Ahnung. Das ganze ist ein OMV 5 Paket, bei dem ich Proxmox zwar mal ausprobiert, dann aber verworfen habe. Darum wundert es mich, daß da trotzdem der Proxmox Kernel läuft.

Im Moment beschäftige ich mich aber auch damit, wie ich von der Systemplatte ein Backup ziehen und bei Bedarf wieder aufspielen kann. Denn OMV 6 ist schon vor einiger Zeit veröffentlicht worden und da wäre es vielleicht angebracht, das Upgrade zu installieren. Da das auf Debian 11 aufbaut, wird da ja jede Menge ausgewechselt und es stellt sich mir die Frage, ob das nicht evtl. das Problem löst. Oder täusche ich mich da?

Benutzeravatar
heisenberg
Beiträge: 3473
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Re: Server beschäftigt nach Löschen

Beitrag von heisenberg » 07.12.2022 00:02:42

Bitte noch:

zfs mount
df -h

Ansonsten: dedup ist an. Ursache gefunden.
... unterhält sich hier gelegentlich mangels wunschgemäßer Gesprächspartner mal mit sich selbst.

Benutzeravatar
bluestar
Beiträge: 2334
Registriert: 26.10.2004 11:16:34
Wohnort: Rhein-Main-Gebiet

Re: Server beschäftigt nach Löschen

Beitrag von bluestar » 07.12.2022 10:21:53

sprint hat geschrieben: ↑ zum Beitrag ↑
06.12.2022 23:50:52
Im Moment beschäftige ich mich aber auch damit, wie ich von der Systemplatte ein Backup ziehen und bei Bedarf wieder aufspielen kann. Denn OMV 6 ist schon vor einiger Zeit veröffentlicht worden und da wäre es vielleicht angebracht, das Upgrade zu installieren. Da das auf Debian 11 aufbaut, wird da ja jede Menge ausgewechselt und es stellt sich mir die Frage, ob das nicht evtl. das Problem löst. Oder täusche ich mich da?
Nach der Ausgabe von zfs mount und df -h wie von heisenberg vorgeschlagen können wir dir zumindest was das Backup angeht weiterhelfen. Um dein Problem zu lösen gibt es zwei Ansätze, am besten und einfachsten wäre es du würdest komplett neu installieren ohne Deduplikation.

Das aktivieren von Deduplikation verändert das Verhalten von ZFS grundlegend und selbst, wenn du die Deduplikation jetzt wieder abschalten würdest, dein ZFS nicht mehr so verhalten wie komplett ohne Deduplikation - der Speicherbedarf für die Deduplikationstabelle bleibt bestehen.

Ich rechne bei ZFS mit Deduplikation etwa 5GB an zusätzlichem RAM Bedarf pro TB nutzbarem Speicherplatz, bei dir wären das 4 * 5GB = 20GB an RAM ausschließlich für die Deduplikation.

Antworten