mgutt

Yes. Finally you have the same result. It seems so. I tested it and Plex creates the complete movie file, before it is downloaded through the client. My RAM Disk is limited to 6GB and as you can see it is automatically removed after the file hits this limit: This means we need 10 to 50GB per movie, depending on the size of the movie. But there is another problem. Multiple downloads per user, creates at least two parallel transcodes: I did not tested multiple users, but I think this will be even more. So we really need to be able to change the download transcoding path somehow or we are forced to use an SSD for all transcodes or install much more RAM 🙈

Jo, korrekt. Ein Bug, den es leider schon ewig gibt.

Das ist keine Fehlermeldung, sondern einfach das BIOS was kein Bootmedium gefunden hat. Also deine ISO funktioniert nicht.

Ok. Gut zu wissen, dass man bei BTRFS also defragmentieren muss, obwohl man SSDs hat ^^ Das hat aber nur "total" verkleinert und nicht "used" oder? Denk dran, dass die Metadaten alleine 2GB belegen und dies auch im RAID1. Bei BTRFS steige ich da nicht ganz durch, aber es liegt wohl an dem Copy on Write. Da werden dann bei Änderungen der Daten nicht in die selben, sondern in neue Datenblöcke geschrieben: https://en.wikipedia.org/wiki/Copy-on-write#In_computer_storage Und ich denke mal, dass die bisher verwendeten Bereiche erst durch die Defragmentierung so richtig frei werden. Aber studiert habe ich BTRFS jetzt auch nicht 😅

No. By that you create the dir /tmp/PlexRamScratch inside of the container, which will be a ram disk inside of your container and as your plex server writes to /transcode, it won't use it. It would only use it, if you change /transcode to /tmp/PlexRamScratch in the transcode settings. By that you could delete all your other changes like the script and the mounted container path as everything happens inside the container then. Thats why I changed the manual as it became easier. But finally this won't solve your problem. Your problem is that the download feature fills up the /transcode dir and as you limited it to 8GB, you can't solve this without making it much bigger. But why does the download feature fill up the /transcode dir? Is this a new behavior? Is it possible to change the dir for download transcodes?

Ich habe mal eine Ubuntu VM aufgesetzt und es getestet. Mein Script läuft auch auf Ubuntu fehlerfrei. Wie hast du es gestartet? Ich vermute mal mit "sh script.sh"? Das ist falsch, weil das ein Bash Skript ist. Also wenn "bash script.sh" oder einfach "/pfad/script.sh". Dann zu den Hardlinks. Beim Abholen gab es wie zu erwarten gar kein Problem. Beim Senden zu einem Ubuntu SMB Share hatte ich dann wie du das Problem, dass keine Hardlinks erstellt wurden. Also habe ich die Unix Extensions und SMB1 (NT1) aktiviert: unix extensions = yes server min protocol = NT1 client min protocol = NT1 [backups] comment = backups on ubuntu path = /home/marc/backups read only = no browseable = yes writeable = no read list = write list = marc case sensitive = auto preserve case = yes short preserve case = yes force user = root Wie man sieht habe ich außerdem den User "root" erzwungen, denn nur so ist rsync in der Lage die Dateirechte zu setzen. Und im rsync Skript habe ich das am Anfang ergänzt, damit er das Ziel über SMB1 mountet: mkdir -p /mnt/remotes/ubuntu_backup_smb1 mount -t cifs -o username=marc,password=<password>,vers=1.0 //ubuntu/Home /mnt/remotes/ubuntu_backup_smb1 Und zum Schluss wieder unmounten: umount -l /mnt/remotes/ubuntu_backup_smb1 rmdir /mnt/remotes/ubuntu_backup_smb1 Aber abholen über Ubuntu ist immer noch die beste Methode, weil ein gehackter Unraid Server dann nicht ans Backup kommt.

Wenn du diesen Login gespeichert hast, dann ja. Danach fragt Windows aber nicht mehr nach einem Login. Also wirst du noch gefragt? Dann hat Windows den Login nicht gespeichert. Wenn schon beim Anklicken ein Fehler kommt, dann hat Windows einen Login verwendet (den falschen).

Hättest du dann gesehen. Ist aber nichts da. Dann ist es einfach klassisch die Differenz zwischen "du" und "df". "du" addiert alle Dateigrößen und "df" schaut einfach nur in den Superblock des Dateisystems. Das Dateisystem kann durchaus reservierte Datenblöcke enthalten, die gar nicht real als Datei vorhanden sind. Manchmal hängen zB Dateien im Löschzustand fest, was man zB so ermitteln kann: lsof +L1 Falls da nichts auf /mnt dabei ist, wird es das aber nicht sein. Eventuell wurden gelöschte subvolumes nicht ordentlich entfernt (durch Docker), dann mal das versuchen: btrfs filesystem sync /mnt/cache Oder vielleicht werden mehr Datenblöcke belegt als eigentlich notwendig, so dass eine Defragmentierung hilft: btrfs filesystem defragment -rvf /mnt/cache Ich bin mir aber gerade nicht sicher, ob das auch die "Chunks" bei BTRFS aufräumt. Mach danach auf jeden Fall noch mal das und schau ob sich "total" verkleinert hat: btrfs filesystem df /mnt/cache Wenn nicht, dann musst du einen balance machen. Keine Ahnung was Unraid für einen Wert nutzt, aber probiere es mal so: btrfs balance start -dusage=85 /mnt/cache Damit sollte sich "total" verkleinern, allerdings ist dein Problem ja eigentlich, dass "used" schon viel zu viel belegt. Daher bin ich aktuell echt überfragt.

@daNick73 You are trying to execute a bash script as a shell script. Either you execute "bash backup_rsync.sh" or you use only "./backup_rsync.sh" and let the OS decide which language should be used.

Subvolumes gibt es aber keine oder? btrfs subvolume list /mnt/cache Und es liegt auch nichts unsichtbares auf dem Cache? ls -lah /mnt/cache Weil das "used" in Höhe von 87GiB irritiert mich. Wobei es bekannt ist, dass die Standard Linux Tools mit BTRFS nicht klar kommen. Daher gibt es df und du auch extra für BTRFS: btrfs filesystem du -sh /mnt/cache/* Allerdings ist es eigentlich andersherum. Also das normale du zeigt mehr an, weil es mit den Snapshots nicht klar kommt und daher Dateien doppelt zählt. Bei dir ist es aber andersherum?!

Und was gibt das aus? btrfs device usage /mnt/cache Und: btrfs filesystem df /mnt/cache

Eins muss man ja sagen. Du ignorierst konsequent, dass überall TB steht ^^

Man könnte versuchen, dass nur der Unterordner mit den Dateien auf dem Array landet und der Rest auf dem Cache. Ich habe Nextcloud testweise vor 3 Tagen installiert. Seitdem hat sich in /data nichts getan. Dann habe ich mich eingeloggt und folgende Pfade wurden aktualisiert: /data/owncloud.db /data/<username>/cache Nach löschen einer Datei: /data/owncloud.db /data/<username>/files /data/<username>/files_trashbin Daraus schließe ich, dass du /data einfach auf den Cache linken musst und /data/<username>/files und /data/<username>/files_trashbin auf das Array. Leider für jeden Usernamen einzeln und bevor man neue User hinzufügt, muss man das ebenfalls machen (ansonsten landen deren Dateien auf dem Cache). Natürlich muss dafür erstmal der Container gestoppt werden und /data ohne /data/<username>/files bzw /files_trashbin auf den Cache verschoben werden, da du ja bereits ein laufendes System hast. Wenn du über die config.php den Cache-Pfad in data/cache/$user änderst, brauchst du nur /data/<username> für jeden User auf das Array verlinken und nicht noch explizit die files-Unterordner. Alternativ ändert man den Cache-Pfad und verlinkt nur /data/cache und die /data/owncloud.db auf den Cache und lässt /data auf das Array linken. Dann muss man nicht alle Userpfade einzeln angeben. Kommt drauf an was du noch so an Dateiänderungen erkannt hast. Wobei owncloud.db bei mir denke ich nur existiert, weil ich beim Testen keine externe SQL Datenbank verwendet habe. Vielleicht aktualisiert sich bei dir ja nur /data/<username>/cache?! Dann müsstest du einfach nur den Pfad auf die SSD verbannen. Also zb im Container auf var/www/html/config/cache/$user, der ja eh schon auf der SSD liegt. Oder vielleicht in /tmp/$user und das mit /tmp/nextcloud/tmp verlinken? Also in den RAM von unRAID? Ich weiß leider nicht wie groß die cache Dateien sein können. In jedem Fall eine ziemlich dämliche Pfad-Struktur, die Nextcloud da umgesetzt hat. Bitte aber in jedem Fall vorher Backups machen.

Also du hast jetzt 22.2.1? Darin ist der Patch ja enthalten.

Wenn du regelmäßig Daten aus deinem HDD Array benötigst, ist dein Setup falsch. Heiße Daten gehören auf den SSD Cache. Oder du erstellst dir einen separaten HDD Pool. Aber mit dem lahmen HDD Array hantiert man eigentlich nicht dauerhaft herum. Ansonsten kannst du das ziemlich easy per Skript umsetzen. Als Cron Schedule zwischen 6 und 20 Uhr alle 15 Minuten auslösen: https://crontab.guru/#*/15_6-20_*_*_* Und pro Disk eine solche Zeile: dd if=/mnt/disk1 of=/dev/null bs=1 count=1 seek=$(shuf -i 1-1000000 -n 1) Dann liest er 1 Byte von einer zufälligen Stelle der Disk (ist wichtig, weil das Byte danach im RAM zwischengespeichert wird und bei Wiederholung nicht mehr von der Disk abgerufen wird), was den Sleep Timer wieder zurücksetzt.

Und was ist, wenn eine SSD ausfällt? Das wäre nur so, wenn du eine Parität verwendest. Ohne Parität, läuft jede Array Disk für sich alleine. Aber warum sollte man ein Array oder überhaupt einzelne Disks ohne Ausfallsicherheit haben wollen? Ich sehe da kein Problem. Eine M.2 als Parität und der Rest vom Array kann dann SATA oder M.2 sein wie du magst. Solange ein Parity Check keine Fehler resultiert, sind die SSDs fürs Array geeignet. Alternativ erstellst du ein ZFS RAID aus den SSDs und packst in das Array einen leeren USB Stick. Geht auch. Oder eben alles ins Array ohne Paritat, wenn für dich Ausfallsicherheit kein Thema ist.

Shares > Ordner Symbol von "appdata" > LOCATION Sind alle Dateien auf dem Cache oder wird auch eine Disk angezeigt? Wenn alles auf dem Cache liegt, kannst du den Pfad problemlos ändern. Zu beachten ist, dass man die Dateien nicht von der SSD runternehmen darf, solange der Container läuft. Also Appdata muss auf Prefer eingestellt bleiben. Sollte man das auf Yes ändern wollen, muss man erst alle Pfade der Cotnainer zurück in /mnt/user ändern.

Ja. Man stellt 100MB ein und so schreibt er direkt alles weg. Wobei der Schreibpuffer wirklich nur beim Schreiben neuer Daten aktiv ist. Da wird also nicht ständig was im RAM gehalten.

Unraid spielt keine Rolle bei diesem Feature. Das ist einzig Sache von Samba Server der Ubuntu Maschine. War der Eintrag denn schon drin oder hast du den hinzugefügt? Danach Samba neu gestartet? Edit: es scheint als müsste man explizit SMB1 dafür verwenden: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1883234 Du kannst alternativ übrigens auch mit SSHFS mounten. Oder NFS wäre auch noch eine Option.

Die IronWolf SSDs brauchst du nicht bzw ich empfehle jetzt nur noch Samsung SSDs, da die die wenigsten Probleme machen. Die IronWolf sind eigentlich auch nie im Angebot. Beim RAM hol lieber 1x 16 als 2x8. So hast du mehr Aufrüstpotential und meiner Ansicht nach kann man nie genug RAM haben. Wäre eines dieser Boards nicht besser? Also 2x M.2 und 8x SATA: https://geizhals.de/?cat=mbp4_1200&xf=11924_2~1244_8&sort=r&hloc=at&hloc=de&v=e Kommt natürlich drauf an was du vor hast. Mein Lieblinge sind nach wie vor das C246M und W480M. Die findest du unter Xeon.

Ich finde 4TB ist eine Grenze wo man über SSD Only nachdenken sollte. Also separaten Cache weglassen und zb nur SanDisk 3D Ultra 4TB verbauen (nicht die billigen Plus). Ob jetzt im Array oder Pool, kann man dann immer noch sehen. Toshiba haben meistens keine Garantie für Endkunden. Bitte mit dem Händler klären. Bei kleinen HDDs auch immer vergewissern, dass es CMR und keine SMR sind. Ansonsten kannst du kaufen was du magst. Schlechte HDDs gibt es nicht (mehr). Bei AMD kannst du die iGPU nur für Transcoding und unRAID nutzen, aber nicht in VMs. Das geht nur mit Intel und auch nur bis zur 10ten Generation.

Nun dann funktionieren die Unix Extensions des Samba Servers nicht. Sicher, dass deine Config korrekt ist und auch geladen wurde? Sicher, dass der Share selbst diese Regel nicht aushebelt? Das kann nur eine Kleinigkeit sein. Ich schaue mal, dass ich herausfinde, wo es in Ubuntu hakt.

Nein. Sollte sogar die sicherste Methode sein.

Nein und daran wird sich erstmal auch nichts ändern, da denke ich eine Testprozedur entwickelt werden muss, die eine ungeeignete SSD erkennt. Bis dahin muss man es selbst ausprobieren. Also Array mit Parity, Dateien löschen, Garbage Collection abwarten und einen Parity Check machen. Wenn keine Fehler auftreten, ist die SSD geeignet. Wenn man auf Nummer sicher gehen will, nimmt man Enterprise SSDs wie Samsung SM883 oder PM897. Gegen "normale" Samsung spricht aber meiner Ansicht nach auch nichts.

Link? Kommando? Screenshots?