Jump to content

MaStr

Members
  • Posts

    4
  • Joined

  • Last visited

About MaStr

  • Birthday 12/19/1983

Converted

  • Gender
    Male
  • Location
    Germany

MaStr's Achievements

Noob

Noob (1/14)

0

Reputation

1

Community Answers

  1. Danke dir für die Rückmeldung. Dann wird es wohl zfs werden, denn ich hatte ähnliches ebenso bei meiner Recherche gefunden. Schade, denn ich dachte btrfs wäre inzwischen gereift. Ja, flüchtig finde ich auch idealer, aber ich möchte die VMs einen schnellen Speicher geben. Ich finde, dass der Speicher dann aber auch redundant sein sollte. Ebenso Paperless möchte ich recht synchron zu den Daten haben, dann der Weg zum letzten Backup eher unangenehm sein könnte. Zumindest kann ich mit raid1 ruhiger schlafen. Alles was mit einem Backup getan ist, läuft derweil schon auf dem orangePi5 und wird dann über ein tägliches Backup gesichert. Ich hatte auch schon über ein zweites Pool device nachgedacht, habe es dann aber wieder verworfen. Irgendwie tue ich mir schwerer als ich sollte ☺️🫣
  2. Ich löse es jetzt so, dass ich noch eine 2TB sata SSD für den Cache hole. Die zwei 1TB SSDs fliegen dann raus. so wird das setup homogener. Cache dann btrfs raid 1 oder zfs. Das werde ich noch würfeln.
  3. Hallo zusammen, Ich brauche mal eure Hilfe und Wissen zum Thema Plattenkonfiguration für das System. Irgendwie habe ich mich gerade so ein wenig an die Wand gearbeitet und ich weiß nicht mehr weiter. Was ist die Ausgangsbasis? Das ZielBild ist grundsätzlich den Stromverbrauch in meiner Server Ecke zu reduzieren. Aktuell benutze ich ein großes QNAP auf dem zwei VMs und eine handvoll Docker Container laufen. Ein Teil der Workload ist inzwischen schon auf ein OrangePi5 verlagert worden. Ich habe nicht viel rechenintensive Software laufen, primär iobroker und paperless. Paperless (mit Datenbanken etc) soll auf dem UnRAID System später laufen. Die eine VM sind ein Yunohost System wo schon etwas IO stattfindet. Das andere System ist mehr so ein Utilities System was hauptsächlich idled. Letzteres wird eventuell sogar vor dem finalen Umzug einfach abgelöst. Auf Basis meiner persönlichen Erfahrung mit QNAP unter der Tatsache, dass ich nicht alle Daten gleichzeitig im sofortigen Zugriff brauche, ist die Entscheidung auf ein neues UnRAID System gefallen. Ich erhoffe mir von der etwas anderen Architektur der Plattenraids etwas Einsparungen. Momentan sind die Stromkosten halt irgendwie hauptsächlich „Bereitstellungskosten“, da so wenig Last da ist.. anstatt konkret viel Arbeit zu verrichten. Im Kontrast arbeitet das QNAP permanent stark auf den Platten und es ist total intransparent was überhaupt da passiert. Ich habe mir verhältnismäßig stromsparen Hardware beschafft. Zwischendurch (mit den ersten Tests) hatte ich auch ein gebrauchtes Bord, welches CRC Fehler auf einem SATA Port erzeugte. Ich baue das System aus neuer gebrauchter Hardware und Hardware aus meinem Keller zusammen. Da ich mal hier das, dann mal dies besorgt und dann auch noch im Keller ein paar Sachen habe, ist die Hardware sehr heterogen. Da ich jetzt schon weit über meinem geplanten Budget bin, würde ich gerne vermeiden nochmal Geld in Form von Hardware reinzustecken. Folgende drei von mir gebrauchte Festplatten sind für den Array vorgesehen : 3x WD Black 4 TB Für den Cache im Raid 1. 1x 1TB NVMe SSD 1x 1TB SATA SSD Zudem hatte ich in einem spontanen Kauf eine 2 Terabyte SATA SSD besorgt. Der erste Gedanke und Test war, diese Platte im Array mitlaufen zu lassen, um dort die VM im Lese und Schreibbegriff zu haben. ich hatte eine steile Lernkurve vor allen Dingen, auch mit dem Blick auf dem Einzug auf das System, der noch nicht stattgefunden hat. Ich hatte jetzt circa 1-2 TB umkopiert und nach einer Woche das erste Mal ein Parität Check gemacht. Natürlich mit direkt über 1000 Fehlern, und ich vermute, dass das alte Mainboard hier irgendwo noch dafür mit verantwortlich war, oder die SSD im Array lief und ist nicht so funktioniert, wie ich es gedacht hab. Oder vielleicht mal ein unkontrolliertes beenden gewesen, weil ich Schwierigkeiten mit dem mover hatte (ticket dazu ist auf). Jetzt habe ich das bisher finale System noch mit dem MemCheck getestet, was unauffällig war. Ich habe das UnRAID jetzt einfach noch mal zurückgesetzt (auch btrfs als Dateisystem überall) und mich noch mal mit dem Thema SSD im Array auseinandergesetzt. Jetzt bin ich ratlos, was ich tun soll und da kommt ihr ins Spiel. Gedanklich bin ich an dem Punkt, wo ich die VMs mit den Containern auf dem Cache laufen lasse und gut ist. Eventuell dann Backups der Anwendung auf den Array auslagern. Dafür ist genug Platz auf dem Cache und er ist redundant. Aber wo soll ich die zwei Terabyte SSD am besten reinpacken? Ich hatte überlegt die eine einfach mit den in den Cache Pool zu werfen. Laut btrfs Rechner komme ich dann auf 2TB bei Raid1 aber UnRAID sagt mir, dass nur 1 TB frei ist (mit df scheint der richtige wert angezeigt zu werden). Oder liegt das hier einfach an der blöden Reihenfolge (1TB nvme , 1TB sata, 2TB sata)?! Das erscheint mir bisher am sinnigsten. Oder geht doch vernünftig die Nutzung der ssd im Array? Laut Doku eher nicht, oder? Oder sollte ich sie einfach als weiteren Pool deklarieren, aber dann wäre sie „ungeschützt“. Ich habe schon so viel geschrieben, wollt ihr noch etwas wissen? Was ist eure Meinung? Ich bin ein wenig ratlos. Danke im Voraus, liebe Grüße Matthias
  4. Hello all, yes, I'm pretty new to UnRAID but I might have discovered a bug, which bothers me. I was doing my first step in datamigration and migrated 1:1 copies of a laptop-backup folder. This 1:1 copy contained special files like "socket" or "named pipes". These files are created by steam and can be leftovers. The mover tried to move my files from the cache to the array but at some point it stopped. I figured out, that the move executable stalls when "mover" tries to move the files. During the progress of cleaning up my cache, I learned about different mover cli commands (mover stop) and worked my head around what's going on. Before I needed to shutdown the system, I ended up with 5 or 6 "move" processes, unable to terminate with SIGTERM or SIGKILL (this is a real issue, IMHO). The main problem is, that "mover" keeps stuck at those items and you can't easily get around this issue. Like said above, I already rebooted the system. I try to recreate it (pretty sure I can) and will upload the diagnostic data and logs as soon as I have it reproduced. Best regards Matthias logfile of test: root@Raven:/mnt/user/testing# ls -l total 0 prw------- 1 matze 1000 0 Oct 12 2022 steam.pipe| root@Raven:/mnt/user/testing# mover mover: started file: /mnt/cache/testing/steam.pipe ------ # 2nd Window root@Raven:/proc# ps -ef | grep move root 1889 25989 0 15:45 pts/0 00:00:00 /bin/bash /usr/local/sbin/mover root 1906 1889 0 15:45 pts/0 00:00:00 /usr/local/bin/move root 2359 31832 0 15:45 pts/1 00:00:00 grep move root@Raven:/proc/1906# ls fd -l total 0 lr-x------ 1 root root 64 Oct 1 15:45 0 -> pipe:[176677] lrwx------ 1 root root 64 Oct 1 15:45 1 -> /dev/pts/0 lrwx------ 1 root root 64 Oct 1 15:45 2 -> /dev/pts/0 lr-x------ 1 root root 64 Oct 1 15:45 3 -> /mnt/user/ root@Raven:/proc# kill 1906 root@Raven:/proc# ps -ef | grep move root 1889 25989 0 15:45 pts/0 00:00:00 /bin/bash /usr/local/sbin/mover root 1906 1889 0 15:45 pts/0 00:00:00 /usr/local/bin/move root 5248 31832 0 15:48 pts/1 00:00:00 grep move root@Raven:/proc# kill -9 1906 root@Raven:/proc# ps -ef | grep move root 1889 25989 0 15:45 pts/0 00:00:00 /bin/bash /usr/local/sbin/mover root 1906 1889 0 15:45 pts/0 00:00:00 /usr/local/bin/move root 5430 31832 0 15:48 pts/1 00:00:00 grep move root@Raven:/proc# mover stop mover: stopped ---- # first window Terminated root@Raven:/mnt/user/testing# root@Raven:/mnt/user/testing# ps -ef | grep move root 1906 1 0 15:45 pts/0 00:00:00 /usr/local/bin/move root 6231 25989 0 15:49 pts/0 00:00:00 grep move raven-diagnostics-20231001-1550.zip
×
×
  • Create New...