• 0 Posts
  • 22 Comments
Joined 1 year ago
cake
Cake day: June 14th, 2023

help-circle
  • Not really with mdadm raid5. But it sounds like you like to live dangerously. You could always go the BTRFS route. Yeah, I know BTRFS Raid56 “will eat your data”, but you said it’s nothing that important anyways. There are some things to keep in mind when running BTRFS in Raid5, e.g. scrub each disk individually, use Raid1c3 for metadata for example.

    But basically, BTRFS is one of the only filesystems that allows you to add disks of any size or number, and you can convert the profile on the fly, while in use. So in this case, you could format the new disk with BTRFS as a single disk. Copy over stuff from one of your other disks, then once that disk is empty, add it as a additional device to your existing BTRFS volume. Then do the same with the last disk. Once that is done, you can run a balance convert to convert the single profile into a raid5 data profile.

    That being said, there are quite a few caveats to be aware of. Even though it’s improved a lot, BTRFS’s Raid56 implementation is still not recommended for production use. https://lore.kernel.org/linux-btrfs/20200627032414.GX10769@hungrycats.org/

    Also, I would STRONGLY recommend against connecting disks via USB. USB HD adapters are notorious for causing all kinds of issues when used in any sort of advanced setup, apart from temporary single disk usage.



  • Mislabeled files, not so much. Since there isn’t really a way to verify the content until it’s downloaded. You can adjust things like which file sizes are considered a certain quality, e.g. HD or 4k. But one approach could be that you define tags for release groups which you know and trust. And give those tags a higher score. This should lead to releases by those groups being preferred.

    You can of course add multiple tags with positive and negative scores. For example I use tags to give a higher score to releases that have 5.1 audio, or which are non-hdr.







  • Nimm einen zweiten PC, z.b. Laptop und log dich per SSH ein und folge dem syslog, also z.b. mit “journalctl -f” Und lass das so laufen und benutze deinen Deskop PC bis er sich wieder aufhängt. Mit etwas Glück bekommst du vielleicht irgendeine interessante Fehlernachricht zurück. Ausserdem wäre interessant ob du bei einem aufhänger, dich noch per SSH verbinden kannst zu der Kiste oder nicht. Wenn z.b. per ssh noch alles geht, aber der Desktop nicht reagiert dann grenzt es das ganze schonmal etwas ein.

    Wenn du meinst dein Laptop hat die exact gleiche Konfiguration, was heisst das genau? Dein desktop hat sicherlich keine mobile CPU oder GPU, das heisst da sind schonmal unterschiede.

    Tritt das Problem immer erst nach einer gewissen Zeit auf? Oder manchmal schon direkt nach dem start?

    Die tatsache das nachdem du einen KDE spin booten wolltest, nur ein schwarzer Bildschirm kam, lässt mich auf die GPU schliessen. Falls die Fehlerhaft ist, kann es ziemlich schwierig sein das zu debuggen, vor allem wen der Fehler nicht konstant reproduzierbar ist.

    Also strom probleme können ihre spuren hinterlassen. Da muss es nicht heissen das das OS davon betroffen ist, sonder im schlimmsten Fall die Hardware. Das genau zu identifizieren kann z.b. schwierig sein. (Instabile Lötstelle, defekter Resistor, etc…)

    OS Neuinstallieren kann man machen, aber ich würde eher mal verschiedene LiveUSB distros ausprobieren und die mal nen Tag lang laufen lassen und sehen ob das Problem auch da auftritt.

    Bleibt die Kiste laufen, wenn du sie nicht benutzt? Also im idle Betrieb, oder hängt es sich da auch auf?

    Mit motherboards ist das so ne Sache. Die können manchmal ziemlich zickig sein, je nach Hersteller und Firmware version. Egal ob übertaktet oder nicht, oder auch wenn alles auf default settings ist. Von BIOS bugs mal ganz zu schweigen. Ein guter Ansatz ist hier, das man z.b. alle strom sparsachen abstellt. Sowohl im BIOS als auch in Linux selber. Bluetooth, WLan und Netzwerk chips können da manchmal auch zickig sein. Ansonsten kannste probieren alle unnötige onboard hardware im bios zu deaktivieren. Also z.b. wlan, bluetooth, etc…

    SSDs und NVMEs funktionieren oft einwandfrei bis sie es plötzlich nicht mehr tun. Da hilft auch S.M.A.R.T. nicht viel weiter, weil man oft keine vorwarnung bekommt. Bei rotierenden Platten schon eher.

    Ich nehme mal an deine CPU und Motherboard hat keine onboard grafikkarte? Eventuell wäre das auch eine Möglichkeit. Praktisch die dedizierte GPU auszubauen, und nur mit der lahmen onboard karte zu testen.

    Was du auch probieren kannst ist linux auf der maschine im reinen konsolen modus zu betreiben und dann z.b. einen vnc server darauf starten und vom laptop aus gewisse graphische desktop applikation auszuprobieren. Dann kannst du z.b. die GPU als fehlerquelle ausschliessen.

    Im Prinzip ist das grösste Problem hier, alle möglichen unbekannten Variablen. “Liegts vielleicht an …?” Gehe systematisch vor, damit du eins nach dem anderen ausschliessen kannst. Eventuell auch protokollieren unter welchen Umständen das Problem auftritt. Wie lang lief die Kiste etwa, was hatte ich grad alles offen, usw…












  • Containers, unless you have a specific need for a VM.

    With a VM you have to reserve resources exclusively. If you give a VM 2gb of ram, then that’s 2gb of ram that you can’t use for other things, even if the guest OS is using less.

    With Containers, you only need as many resources as the process inside the container requires at the time.