mgutt

Bei Schwiegermutter passieren komische Dinge im Garten ^^ Dh ich werde ihr die Tage einen Lenovo M920x mit Coral Dual TPU ausstatten und Frigate darauf installieren und mich dann auch mal mit der Thematik auseinandersetzen. Bei der Kamera hat man ihr die Tapo C500 empfohlen. Nach einer kurzen Recherche bei Amazon ist die sehr gut bewertet, aber nur 1080p und ob die optimal mit Frigate laufen wird... bei Amazon sind dann so "Marken" wie zB ieGeek, eufy, Reolink, Galayou, etc sehr gut bewertet. Bei Reddit empfiehlt man dagegen eine Kamerae, die möglichst viel Auswahl bei den Streams in Sachen Codec und Qualität anbietet und daher tendiere ich eher zu einer professionellen Hikvision. Um flexibel zu bleiben dachte ich an eine mit WLAN, PoE und integriertem IR Strahler. Viel Auswahl hat Hikvision da nicht: Ich denke ich probiere die DS-2CD2546G2-IWS, also die Variante mit empfindlicherem Sensor und WLAN. Die DS-2CD2543G2-IWS wäre aber denke ich auch nicht schlechter. Ob Hikvision es irgendwann lernt und das Sortiment man entschlackt, statt für jeden Blödsinn ein eigenes Modell zu entwerfen😅

Auf keinen Fall, weil das nur Probleme macht. Wenn dann mit ASM1166 Karte (M.2 oder PCIe). Optimal wäre natürlich ein Board mit ausreichender Anzahl SATA Buchsen. Kontron Boards der aktuellen Generation sind sparsam und haben meine ich bis zu 6 Buchsen. Ansonsten gerne auch nach älteren Boards schauen.

And did you check if hardware transcoding is working?

Dann hast du in beiden Fällen keine deutsche Tastatur eingestellt. Beim Bearbeiten der VM musst du German auswählen.

Dafür muss man nicht das Template bearbeiten. Man klickt beim Pfad einfach auf EDIT.

Nö. Das Skript verbindet sich per SSH mit dem Rsync Server des Quell Servers. Auf dem Backup Server braucht es keinen Container. Da der Pfad nur lesend freigegeben wird (siehe Container Einstellungen), dürfte das egal sein. Außer du hast sehr sensible Daten auf dem Quell Server, die du nicht sicherst und die niemals jemand lesen darf. Aber dann würde ich fragen warum die nicht verschlüsselt sind 😉 Noch hast du es nicht verstanden 😁 Nein. Der Backupserver darf vom Quellserver nur lesen. Andersherum existiert überhaupt keine Verbindung. Korrekt. Das kann man lösen, in dem man das Skript zusätzlich lokal ausführt und /mnt/user/appdata nach /mnt/user/backup_appdata sichert. Das dann zb mit 1 Tag Aufbewahrungszeit. Beim Backupserver stellt man das Skript dann so ein, dass es nicht appdata sichert oder man sichert es einfach auch mit, aber benutzt bei einer Wiederherstellung Härtefall nur die Dateien aus backup_appdata.

Optimal wäre es, wenn das Skript auf dem Backup Server läuft und der nur lesend auf den Quellserver zugreifen kann. Dh der rsync Docker ist dann sinnvoll. Ansonsten nutzt der Backupserver den root Login, was dich extrem anfällig bei Attacken macht.

The error is written to this logs. I still don't understand why NPM is hiding them in a different log file instead of writing them to the default container logs.

Nun, alles was ich an Messergebnissen bisher gesehen oder selbst gemessen habe und die Preise sind mindestens doppelt so hoch wie mein aktuelles Setup (C246N+Xeon+8xHDD+64GB ECC RAM). Meiner Ansicht nach, wird völlig am Bedarf vorbei produziert.

Die sind bis auf den 10G Controller baugleich. Sind zwei verschiedene Intel Controller, je nach Verfügbarkeit verbaut worden. In meinen Augen ist alles aktuell Schrott. Zu teuer und zu ineffizient. Mal sehen was nächstes Jahr kommt 😅

Übrigens hat rsync die geänderte Datei erst nicht erkannt. Ich muss explizit mit checksum arbeiten: root@thoth:~# rsync --progress --archive --verbose /mnt/user/*/*/Paul\ Kalkbrenner\ -\ A\ Live\ Documentary\ \(2010\)/Paul\ Kalkbrenner\ -\ A\ Live\ Documentary\ \(2010\)\ DE\ PART2.mkv /mnt/horus2nd/MovieOP/Paul\ Kalkbrenner\ -\ A\ Live\ Documentary\ \(2010\)/Paul\ Kalkbrenner\ -\ A\ Live\ Documentary\ \(2010\)\ DE\ PART2.mkv sending incremental file list sent 110 bytes received 12 bytes 244.00 bytes/sec total size is 15,872,430,968 speedup is 130,101,893.18 root@thoth:~# rsync --progress --checksum --archive --verbose /mnt/user/*/*/Paul\ Kalkbrenner\ -\ A\ Live\ Documentary\ \(2010\)/Paul\ Kalkbrenner\ -\ A\ Live\ Documentary\ \(2010\)\ DE\ PART2.mkv /mnt/horus2nd/MovieOP/Paul\ Kalkbrenner\ -\ A\ Live\ Documentary\ \(2010\)/Paul\ Kalkbrenner\ -\ A\ Live\ Documentary\ \(2010\)\ DE\ PART2.mkv sending incremental file list Paul Kalkbrenner - A Live Documentary (2010) DE PART2.mkv 15,872,430,968 100% 221.56MB/s 0:01:08 (xfr#1, to-chk=0/1) sent 15,876,306,241 bytes received 35 bytes 91,506,088.05 bytes/sec total size is 15,872,430,968 speedup is 1.00 Dh die MKV war gleich groß und hatte das selbe Dateidatum usw. SnapRAID hatte beim Fix wirklich nur ein paar Bytes in der MKV geändert. Also etwas, was sicher niemand so haben möchte. Naja, jedenfalls stimmt die Hashsumme jetzt wieder: # md5sum /mnt/horus*/MovieOP/Paul\ Kalkbrenner\ -\ A\ Live\ Documentary\ \(2010\)/Paul\ Kalkbrenner\ -\ A\ Live\ Documentary\ \(2010\)\ DE\ PART2.mkv 92203fcd40fa6c0dfa9b984e333e95c7 /mnt/horus2nd/MovieOP/Paul Kalkbrenner - A Live Documentary (2010)/Paul Kalkbrenner - A Live Documentary (2010) DE PART2.mkv

Ich spiele nach wie vor mit dem SnapRAID Container herum. Die Tage hatte ich eine Fehlermeldung beim wöchentlichen Sync des SnapRAID Pools. Laut der Fehlermeldung gab es bei einem Scrub einen Fehler (unexpected file errors), nur leider sonst keine wirklichen Infos: 2023-12-17 03:00:00,862 [INFO ] ============================================================ 2023-12-17 03:00:00,862 [INFO ] Run started 2023-12-17 03:00:00,863 [INFO ] ============================================================ 2023-12-17 03:00:00,863 [INFO ] Running touch... 2023-12-17 03:00:03,705 [OUTERR] WARNING! With 5 disks it's recommended to use two parity levels. 2023-12-17 03:00:20,307 [INFO ] ************************************************************ 2023-12-17 03:00:20,307 [INFO ] Running diff... 2023-12-17 03:00:23,571 [OUTERR] WARNING! With 5 disks it's recommended to use two parity levels. 2023-12-17 03:00:25,315 [OUTERR] WARNING! Physical offsets not supported for disk 'd1', 'd2', 'd5'. Files order won't be optimal. 2023-12-17 03:00:25,852 [INFO ] ************************************************************ 2023-12-17 03:00:25,859 [INFO ] Diff results: 0 added, 0 removed, 0 moved, 0 modified 2023-12-17 03:00:25,859 [INFO ] No changes detected, no sync required 2023-12-17 03:00:25,860 [INFO ] Running scrub... 2023-12-17 03:00:28,751 [OUTERR] WARNING! With 5 disks it's recommended to use two parity levels. 2023-12-17 03:03:51,432 [OUTERR] WARNING! Unexpected file errors! 2023-12-17 03:04:07,738 [ERROR ] Command 'snapraid scrub' returned non-zero exit status 1. 2023-12-17 03:04:08,017 [INFO ] sending msg 2023-12-17 03:04:08,022 [INFO ] Applying Custom Defaults Daraufhin habe ich mal maunell einen verbosen Scrub gestartet und tatsächlich hat er einen Fehler gefunden, nur wie man sieht hat sich die MKV-Datei gar nicht geändert?! Also wenn die MKV unverändert ist, warum behauptet der beim Scrub, dass es einen "Data error in file" gab?! Hier jetzt das komplette Ergebnis des Scrub: # docker exec -it Snapraid snapraid scrub --verbose Self test... Loading state from /config/snapraid.content... 1071 files 0 hardlinks 0 symlinks 24 empty dirs WARNING! With 5 disks it's recommended to use two parity levels. Using 1162 MiB of memory for the file-system. Initializing... Using 112 MiB of memory for 64 cached blocks. Selecting... Scrubbing... Data error in file '/mnt/horus2nd/MovieOP/Paul Kalkbrenner - A Live Documentary (2010)/Paul Kalkbrenner - A Live Documentary (2010) DE PART2.mkv' at position '21901', diff bits 64/128 100% completed, 2092911 MB accessed in 0:28 8%, 0:00 ETA d1 0% | d2 2% | * d3 0% | d4 8% | ***** d5 2% | * parity 0% | raid 70% | ****************************************** hash 15% | ********* sched 0% | misc 0% | |______________________________________________________________ wait time (total, less is better) 1243108 file errors 0 io errors 1 data errors WARNING! Unexpected file errors! DANGER! Unexpected data errors! The failing blocks are now marked as bad! Use 'snapraid status' to list the bad blocks. Use 'snapraid -e fix' to recover them. Use 'snapraid -p bad scrub' to recheck after fixing. Saving state to /config/snapraid.content... Saving state to /mnt/horus1st/snapraid.content... Saving state to /mnt/horus2nd/snapraid.content... Saving state to /mnt/horus3rd/snapraid.content... Saving state to /mnt/horus4th/snapraid.content... Saving state to /mnt/horus5th/snapraid.content... Saving state to /mnt/horus6th/snapraid.content... 1071 files 0 hardlinks 0 symlinks 24 empty dirs Verifying... Verified /config/snapraid.content in 0 seconds Verified /mnt/horus5th/snapraid.content in 2 seconds Verified /mnt/horus3rd/snapraid.content in 3 seconds Verified /mnt/horus6th/snapraid.content in 3 seconds Verified /mnt/horus1st/snapraid.content in 3 seconds Verified /mnt/horus2nd/snapraid.content in 3 seconds Verified /mnt/horus4th/snapraid.content in 3 seconds Wie empfohlen mal einen "Status" ausgeben lassen: # docker exec -it Snapraid snapraid status --verbose Self test... Loading state from /config/snapraid.content... 1071 files 0 hardlinks 0 symlinks 24 empty dirs WARNING! With 5 disks it's recommended to use two parity levels. Using 1162 MiB of memory for the file-system. SnapRAID status report: Files Fragmented Excess Wasted Used Free Use Name Files Fragments GB GB GB 195 27 31 0.0 3583 4359 45% d1 262 31 35 0.0 4437 3505 55% d2 197 1 2 0.0 3040 4901 38% d3 225 0 0 0.0 3460 4481 43% d4 192 18 18 0.0 3081 4860 38% d5 -------------------------------------------------------------------------- 1071 77 86 0.2 17603 22108 44% 83%|o |o |o |o |o |o |o 41%|o |o |o |o |o |o o |o o 0%|o_____________________________*____________*______*o____*______*_____* 74 days ago of the last scrub/sync 0 The oldest block was scrubbed 74 days ago, the median 74, the newest 0. WARNING! The array is NOT fully synced. You have a sync in progress at 47%. The 85% of the array is not scrubbed. No file has a zero sub-second timestamp. No rehash is in progress or needed. DANGER! In the array there are 1 errors! They are from block 3388744 to 3388744, specifically at blocks: 3388744 To fix them use the command 'snapraid -e fix'. The errors will disappear from the 'status' at the next 'scrub' command. Was macht denn "-e fix", die Datei ändern? Das wäre ja falsch. EDIT: Ok ich habe in der Anleitung "check" gefunden: Ergebnis: # docker exec -it Snapraid snapraid check --filter-error --verbose Self test... Loading state from /config/snapraid.content... 1071 files 0 hardlinks 0 symlinks 24 empty dirs WARNING! With 5 disks it's recommended to use two parity levels. Searching disk d1... Excluding content '/mnt/horus1st/snapraid.content' Searching disk d2... Excluding content '/mnt/horus2nd/snapraid.content' Searching disk d3... Excluding content '/mnt/horus3rd/snapraid.content' Searching disk d4... Excluding content '/mnt/horus4th/snapraid.content' Searching disk d5... Excluding content '/mnt/horus5th/snapraid.content' Selecting... <error> Using 1162 MiB of memory for the file-system. Initializing... Selecting... Checking... recoverable MovieOP/Paul\ Kalkbrenner\ -\ A\ Live\ Documentary\ \(2010\)/Paul\ Kalkbrenner\ -\ A\ Live\ Documentary\ \(2010\)\ DE\ PART2.mkv correct Movie09/12\ Strong\ \(2018\)/12\ Strong\ \(2018\).mkv correct MovieUV/Um\ Klassen\ besser\ \(2012\)/Um\ Klassen\ besser\ \(2012\).mkv correct MovieQR/Der\ Regenmacher\ \(1997\)/Der\ Regenmacher\ \(1997\).mkv correct MovieWX/Was\ Frauen\ wollen\ \(2000\)/Was\ Frauen\ wollen\ \(2000\).mkv 100% completed, 216925 MB accessed in 0:02 1 errors 0 unrecoverable errors WARNING! There are errors! Ok, also scheinbar wollte er die eine MKV wirklich "korrigieren", was wie gesagt falsch wäre. Mal sehen, ob eine der anderen genannten MKVs korrekt sind. EDIT2: Ok, alle MKV-Dateien sind unverändert. Also muss ja die Parität von SnapRAID kaputt sein. Nur warum und warum will SnapRAID die MKV verändern, wenn doch die Parität falsch ist 🤔 EDIT3: Äh ja, ich habe den Fix ausgeführt. # docker exec -it Snapraid snapraid fix --filter-error --verbose Self test... Loading state from /config/snapraid.content... 1071 files 0 hardlinks 0 symlinks 24 empty dirs WARNING! With 5 disks it's recommended to use two parity levels. Searching disk d1... Excluding content '/mnt/horus1st/snapraid.content' Searching disk d2... Excluding content '/mnt/horus2nd/snapraid.content' Searching disk d3... Excluding content '/mnt/horus3rd/snapraid.content' Searching disk d4... Excluding content '/mnt/horus4th/snapraid.content' Searching disk d5... Excluding content '/mnt/horus5th/snapraid.content' Selecting... <error> Using 1162 MiB of memory for the file-system. Initializing... Selecting... Fixing... recovered MovieOP/Paul\ Kalkbrenner\ -\ A\ Live\ Documentary\ \(2010\)/Paul\ Kalkbrenner\ -\ A\ Live\ Documentary\ \(2010\)\ DE\ PART2.mkv 100% completed, 216925 MB accessed in 0:02 %, 0:00 ETA 1 errors 1 recovered errors 0 unrecoverable errors Everything OK Und nun wurde die MKV geändert: # md5sum /mnt/horus*/MovieOP/Paul\ Kalkbrenner\ -\ A\ Live\ Documentary\ \(2010\)/Paul\ Kalkbrenner\ -\ A\ Live\ Documentary\ \(2010\)\ DE\ PART2.mkv e62d45d0b12f60f3ec681a54f0c6d3c7 /mnt/horus2nd/MovieOP/Paul Kalkbrenner - A Live Documentary (2010)/Paul Kalkbrenner - A Live Documentary (2010) DE PART2.mkv # Original: # md5sum /mnt/user/Movie/OP/Paul\ Kalkbrenner\ -\ A\ Live\ Documentary\ \(2010\)/Paul\ Kalkbrenner\ -\ A\ Live\ Documentary\ \(2010\)\ DE\ PART2.mkv 92203fcd40fa6c0dfa9b984e333e95c7 /mnt/user/Movie/OP/Paul Kalkbrenner - A Live Documentary (2010)/Paul Kalkbrenner - A Live Documentary (2010) DE PART2.mkv Das ist ja gruselig. Woher soll man als Anwender denn wissen, dass der gerade die Datei kaputt macht?! Korrekt wäre jedenfalls gewesen die Parität zu korrigieren, warum auch immer diese falsch war 😨 Ich kopiere jetzt wieder die Original MKV zurück. Mal sehen was in Zukunft noch passiert. Klingt aber nicht gerade super das SnapRAID.

Hätte ich nicht gedacht, ist aber wirklich so. Mich erstaunt, dass die für den C256 und jetzt den C266 überhaupt Käufer finden. Die E-2300 CPUs sind super teuer und das werden die E-2400 ja auch sein. Wozu sollte man für zB einen E-2488 doppelt so viel zahlen wie für einen i7-13700K, der ja auch ECC kann und wo es schon W680 und R680E Boards mit AST2600 gibt und wo die CPU neben den 8 Performance Kernen (der E-2488 hat nur die), auch noch 8 Effizienzkerne mit sich bringt, also sogar noch mal deutlich mehr Leistung besitzt. Da draußen muss es echt Leute geben, die ein Problem damit haben, wenn auf dem Produkt "Workstation" steht... "ne das können wir doch nicht in einem SERVER einbauen"🤷‍♂️

Deine Docker Installation, also unterhalb von /mnt/user/system hat irgendeine Macke würde ich sagen. Entweder die Dateien sind kaputt oder deine SSD. Ja und da gehören sie auch hin. Der Cache in Unraid ist persistent. Dh entweder liegen Dateien auf einem Pool oder dem Array. So ähnlich dürfte es passieren. Ich vermute, dass einige Zeit alles ordentlich läuft, aber irgendwann fliegt die USB SSD raus und er schreibt dann in den RAM bzw versucht von diesem zu lesen. Schau einfach bei Tools > Syslog. Ich wette das ist alles voller Fehler. Das ist übrigens ein Grund warum vor USB Datenträgern gewarnt wird. Also die Idee kanns du knicken. Du musst M.2 oder SATA verwenden.

Ganz ehrlich: Ich würde die alle entsorgen / verkaufen. Geh mal von 1W pro HDD aus, wenn du sie nicht verwendest. Bei 10 Platten braucht es dann mindestens eine SATA Karte. Noch mal 2W. Dann laufen die vielleicht am Tag 1 Stunde, wenn man mal was macht. Also sagen wir mal 40 € zusätzliche Stromkosten, nur weil man sehr viele HDDs hat. Und jetzt rechnen wir noch das Geld für die SATA Karte, die zusätzlichen Stromkabel, die zusätzlichen SATA-Kabel, zusätzliche Lüfter, den Aufpreis für das größere Netzteil mit entsprechend vielen Anschlüssen, der Aufpreis für das größere Case usw. Nun noch den Stromverbrauch auf 7 Jahre rechnen und diese Hardwarekosten addieren... da sind dann denke ich 400 € schnell erreicht. Und jetzt schau dir an was eine 14TB Platte kostet: https://geizhals.de/?cat=hde7s&xf=13810_4000&asuch=&bpmin=&bpmax=&v=e&hloc=at&hloc=de&plz=&dist=&sort=r&bl1_id=30#productlist Entweder sind solche Karten heftige Stromschlucker oder sie haben eine miese Performance. Sparsam sind zB SATA Karten mit ASM1166 Chipsatz. Aber wie gesagt ist das unnötig, wenn du einfach direkt größere Platten verwendest.

Sicher ineffizient, denn je nach Netzteil verballert man bei 20W Last zwischen 4 und 8W für nichts. Ganz unten rum, also bei sagen wir 2W Last verhalten sich die Netzteile dann noch mal ganz anders je nach Modell. Ich teste das mal die Tage. Ich hab ja ein RM550x (2021) hier. Viel effizienter geht ja nicht.

Genau das ist der Haken. Woher den Strom nehmen. Und wenn natürlich effizient. Ich habe hier ein Netzteil mit 5 und 12V mit Molex, womit man HDDs extern betreiben kann, aber das war bei meinen Tests sehr ineffizient (man muss dann ja beide Netzteile parallel in den Verbrauch einbeziehen). Ich wollte ja eigentlich mal gemessen haben was auf dem Board so verfügbar ist. Vielleicht gibt es ja irgendwo 5V und man muss nur 12V ergänzen?! Dann könnte man ein effizientes Level VI 12V Netzteil verwenden. Wobei der PCIe Slot ja 12V hat. Da man Grafikkarten verbauen kann, sollte der bis zu 75W nach Spezifikation liefern, wobei davon 66W 12V ausmachen. Das würde für 2 bis 3 HDDs ausreichen. Aber auch da die Frage wie man an diese 12V kommt. Es gibt ja keine ASM1166 Karte, wo man dann noch PINs hat um den Strom für andere Geräte abzuzwacken. Vielleicht ein Fall für https://c-payne.com/ 🤔

Please try all USB ports. In addition test one of the USB onboard connectors with an adapter like this one: https://www.startech.com/en-us/cables/usbmbadapt2

NVMe or you won't be able to exclude USB as the source of the problem 😉

That's why it can be useful to install Ubuntu to check if this could be a reason. Even specific USB ports can influence c states. Yupp

As long you don't connect any drives, you won't see the but which is caused by the old firmware. As long powertop is showing the other states, it should be able to display their usage. If it does not support anything above C3 it won't show them at all. Usually a CPU has one or more PCI bridge devices to provide the lanes for all the PCI devices. You could output a tree to understand it better: https://superuser.com/questions/1768544/how-can-i-understand-the-device-topology Yes and no. If low packages states would be reached, the CPU should throttle to 800 Mhz. But the high frequency is not the reason for the hight pgk c states. Usually the reason are the other devices or the BIOS itself. Please test with the least amount of connected devices as possible. So remove the ASM1166 and maybe play around with the Ethernet/USB ports. For example I tried on a different board to install Ubuntu and removed USB and Ethernet and finally it I found out that it only reached C8 when I disconnected the Ethernet port.

Bei Kleinanzeigen verkauft seiner seins für 200 €. Aber gerade dann heißt es Friss oder Stirb. Also wenn das doch mehr verbraucht, dann Pech. Das Gigabyte Z490i kann wohl sparsam: Ich sag mal zu 90% sollte das Asus auch sparsam sein, aber wissen kann man es nie 🤷 Und ob der Aufpreis lohnt: In jedem Fall besser als einen M.2 Slot zu haben, den man nicht nutzen kann.

Wird man abschalten können. Das WLAN ist außerdem eine Karte. Die kannst du also ausbauen. Den Verbrauch ändert das minimal. Dual Channel brauchst du bei einem Heimserver normalerweise nicht. Ist eher beim Rendern / Gaming interessant. Ich würde 1x 32GB verbauen, damit du auf 64GB gehen kannst. Du wirst dich in Zukunft sonst evtl ärgern, dass du schon alles voll hast. Wenn du NVMe verbauen willst, dann könnte man das machen. Willst du eigentlich RAID1 machen oder nur eine verbauen? Letztere geht auch. Hat den Vorteil, dass nur eine SSD Strom zieht. Der Nachteil ist, dass man regelmäßiger Backups machen muss. Ich mache das zb so. Sollte mal die SSD kaputt gehen, verliere ich die paar Stunden eben. Ach ja stimmt. Das war eine ätzende Einschränkung. Gibt es evtl ein Z490i ohne diese Einschränkung? Davor gab es nämlich einfach keinen CPU M.2 Slot, sondern 2x über den Chipsatz. Diese Boards waren meist auch besser bezüglich der C-States Vergiss den T. Damit spart man nichts. Man kann jede andere CPU auch wie einen T im BIOS einstellen. Es gibt von ADT Link auch Verlängerungskabek für M.2, aber das würde ich jetzt alles nicht machen. Immer am besten ohne extra Karten wenn es geht.

Not with rsync, but with different apps: https://unix.stackexchange.com/questions/3037/is-there-an-easy-way-to-replace-duplicate-files-with-hardlinks Someone asked if it could be added to the nerd tools: Feel free to check that or participate in the thread and ask for it.

Yes. Can be confusing, too: If you would delete the 254G backup and repeat the command, the 154G backup becomes "bigger". And of course: If you delete the 6.0T backup, the 154G backup will "become" 6.x T.