Posts by Sc0rp

    Re,


    Mr. RAID ... o.O ... well ... really?


    Anyway ... relocating the sector can help, but if SMART or better the hdd-controler does not detect the media-error himself, then you'l have a bigger problem. Theoretically should do the controler remap this sector "transparently" ...


    I know an article, which descripes the procedure to "remap" an sector within an mdraid-array, but i can't remember and i have currently to less time to google-fu that by myself ... sry.


    Sc0rp

    Re,

    There were remains from other file systems on them and for unknown reasons mdmadm did not write the new superblocks properly.

    Yeah. That's a bug ... well known for me.


    dd if=/dev/zero of=/dev/sdX bs=1M (replace X with the target drive letter)

    Better use:
    dd if=/dev/zero of=/dev/sdX bs=4096 count=16 (Blocksize is better for 4Kn-drives and 16x4KiB-Blocks will overide any GPT Informations)


    But if you zero the drive, you have to add it to the array again ...


    Sc0rp

    Re,

    Ich habe aktuell 7 HDD's verbaut. Platz ist für 10. Wenn ich jetzt mit "stripe-width=6*X" (was ja in meinem Fall das richtige wäre)

    Japp.



    was passiert dann wenn ich noch eine HDD verbaue? Dann müsste es doch "stripe-width=7*X" sein. Kann man das im nachhinein ändern?

    Gute Frage. Ich weiß nicht, ob man das mit tune2fs später ändern kann, aber die "stripe-width" ist nicht so wichtig wie "stride", "stride" muss passen, ansonsten erleidet dein Verbund einen erheblichen Performanceverlust ...


    Laut dem man für tune2fs kann man später auch noch die "extended options" anpassen ...


    Sc0rp

    Re,

    ich dachte ZFS mit 2GB RAM ist nicht zu empfehlen, oder ist das bei OMV 3 anders?

    Das hat nix mit der OMV-Version zu tun.
    RAM-Cache wird unter Linux immer für File-Caching benutzt, je mehr du davon hast um so mehr wird gecached (zwischengespeichert) - so auch unter ZFS. Bei dir wird lediglich der übliche Performance-Gewinn beim Wechsel von EXT4 auf ZFS nicht spürbar sein, laufen müsste es trotzdem.


    Btw. wenig RAM ist sowieso nicht zu empfehlen :D, welchen nach zu stecken sollte ja kein Problem sein, oder?


    Sc0rp

    Re,

    Muss ich dann beim neu Formatieren irgendetwas beachten? Bzw. gibt es dafür einen Consolenbefehl damit das Dateisystem dann auch wirklich 64 bit ist?

    das kommt darauf an, ob deine e3fsprogs schon entsprechend neu sind - dein dumpe2fs sieht zumindest nicht danach aus :(
    (siehe https://askubuntu.com/question…ion-beyond-the-16tb-limit)


    Also wäre vermutlich der XFS-Weg besser für dein (jetziges) Setup - obwohl ich dir immer noch dringender das OMV-Upgrade ans Herz legen würde (dann kommen auch u.A. neue e2fsprogs!), damit könntest du getrost auf ZFS gehen ...


    Für XFS müsstest du evtl. auch die Console bemühen:

    In dem verwendetem Beispiel erstellen wir ein Raid5 aus 8 HDDs (--> sw=7) und 64k Stripsize (--> su=64k):mkfs.xfs -d su=64k,sw=7 /dev/sdc1

    In deinem Fall wäre das dann wahrscheinlich:
    mkfs.xfs -d su=128k,sw=3 /dev/md127 (ein vier Platten RAID5 mit 128k Stripesize)


    Oder für EXT4 wäre das in Etwa:
    (siehe https://gryzli.info/2015/02/26…t-performance-under-raid/)
    mkfs.ext4 -O 64bit -E stride=X,stripe-width=3*X /dev/md127 (X musst du dir selber ausrechnen, die RAID-Chunk-Size bekommst du von cat /proc/mdstat)


    Sc0rp

    Re,

    Soll ich dann wieder ext4 machen oder XFS? Die Dateien sind recht groß. 10-100 GB pro Datei (Actioncam Videos)

    EXT4 reicht, XFS würde ich nicht anfangen.
    Du musst halt deine neue EXT4-Partiton mit den gleichen Werten (siehe dem dumpe2fs) anlegen ... und das vermutlich via Console.


    Hatte schon mal OMV 3 drauf, aber dann ständige Verbindungsabbrüche per NFS.

    Ursachenforschung betrieben? Nur weil NFS auf einmal Abbrüche hat (was auch hochgradig ungewöhnlich ist) ... sollte man aktuellere Betriebssysteme nicht meiden.


    Sc0rp

    Re,

    Actually, OMV itself (not omv-extras) enables the backports kernel in OMV 3.x and 4.x.

    Okay, and how is this done? Can this be "forced"?


    My last install (media-archive) does not had the backport-kernel anyway nor the OMV-Extras-package ("old" install procedure) showed the backport (installed 4 weeks ago) - so i had to install the backport "manually".


    Sc0rp

    Re,

    Dein geposteter Thread ist leider in engl. und das war nicht meine Fremdsprache in der Schule sondern russisch

    Oh ... noch ein "Ossi" *freu* :D


    Ich benutze Version 2.2.14 (Stone burner) / "Linux Server 3.2.0-4-amd64 #1 SMP Debian 3.2.93-1 x86_64"

    Oha ... da wäre ein OMV-Upgrade vllt. vorher fällig?


    Kann mir dazu bitte jemand schreiben wie ich das machen kann OHNE das das ich alle Daten vorher Sichern muss?

    Naja, es gibt kein "inline" Upgrade, d.h. du kannst es nicht mit einem Befehl innerhalb von EXT4 lösen. Daher musst du die Daten zwangsläuffig i'wo hin bewegen.


    Je nach Füllgrad könntest du vllt. so vorgehen:
    - auf dem jetzt freien Stück deines RAID-Verbundes eine neue Partition (mit 64bit!) erstellen (7,3 TiB)
    - Daten von deiner ersten (alten) Partiton auf die zweite (neue) Partition bewegen
    - dann die erste Partition verkleinern, die zweite vergrößern
    - das solange wiederholen, bis die erste (alte) Partition leer ist - und diese dann endgültig löschen / die neue (zweite) Partiton dann weiterverwenden


    Ansonsten bleiben dir ja nur die Möglichkeiten mit "Tabula rasa" (dein RAID-Verbund interessiert das Dateisystem leider herzlich wenig) - also enweder komplett neues EXT4 mit 64bit machen oder XFS einsetzen. Die Daten müssen dann natürlich auch zwischengespeichert werden ... aber wenn du DAS dann schon komplett neu machen möchtest, solltest du vorher auch OMV auf Version 3 heben ... ZFS mit 2GiB RAM würde ich nicht empfehlen.


    Sc0rp

    Re,

    OMV 3 setzt ja debian 8.9 voraus, also Kernel 3.16. Angeboten wird mir jetzt aber anscheinend ein Update auf 4.9. Deshalb meine nochmalige Frage: Zerschießt es mir dadurch das OMV?

    Nein. Das OMV-Extras-Paket bringt die Installation des Backport-Kernels (v4.9) ja mit ... und gerade bei neuerer Hardware sollte man den auch einsetzen. Zudem unterstützt der neue Kernel auch mehr Stromsparfeatures ...


    Man muss allerdings auf die "wirklich abhängigen" Pakete achten, m.W.n. gibt es Probleme mit dem Docker-Plugin ... das startet dann nicht mehr (weil es im Kernel 4.9 kein "AuFS" mehr gibt, das Docker für seine Container nutzt, da muss man dann u.U. nacharbeiten).


    Sc0rp

    Re,


    IronWolfs are relativly "young" drives, but it seems currently, that they are worth a try (but they operate at 7,2k rpm ... more performance for more temp!) ... WD Red are the usual/common recommendation for NAS-setups - they are realy good suited for private/home office use (you can change to WD Red Pro if you need more performance ...).


    Sc0rp

    Re,


    this looks bad - have any drive SATA-errors too? From plain data given, i would "sdf" change first, then "sdc", then "sdb" ... and may be use anonther vendor/type of harddrives ... btw. which drives do you use actual?


    Sc0rp

    Re,


    OT

    (I mute email notifications and prefer monitoring through other channels, OMV's SNMP implementation for example is quite capable!)

    I got no time for my BPi-R1 to get this working as an "LAN-manager" :( - i would use SNMP too, and some other tools for gathering informations from any connected device in my LAN, but emails on NAS were a very quick (and working) approach - the simplest notifying solution will work better than no one ...
    /OT


    Btw. ich checked my NAS, and the "unattended-upgrades" is not installed ...


    Sc0rp

    Re,


    I don't know about the x86 ISO but on all the various OMV images for ARM boards the 'unattended-upgrades' package is installed by default so even users who 'never change a running system' get security fixes without even knowing

    Oh ... i don't use the ARM nor the ISO either :P, i install OMV always over the Debian-NetInstall-ISO - and this way, the packages are gathered "in download-only-mode" by OMV ... i have to install them by either "clicking" or issuing "ap-get upgrade && apt-get dist-upgrade" on the console ...


    But i would go fine with the "unattended-upgrades" too, it's more secure than anything "manual" ... btw. works this with the email-notification(s) ? (my NAS'es send emails for (possible) updates ...)


    Sc0rp

    Re,


    die OMV-WebGUI führt auch nur ein "apt-get update" aus, und präsentiert das Ergebnis im Browser ... von daher ist es egal ob du die WebGUI benutzt oder die Commando-Zeile ...


    Updates sollten immer und recht zeitnah installiert werden, weil es meistens Sicherheitsaktualisierungen sind.
    Ein Neustart ist in den seltensten Fällen nötig (meist nur bei reinen Kernel-Upgrades, und die kommen bei OMV3 recht selten vor).
    Es wird ja auch nur aktualisiert, was vorhanden (installiert) ist ...


    Sc0rp

    Re,

    If you dont update, you doesnt have a stable system!

    Nope, that's not correct - but you have an unsecure and scruffy system. I assume @Chris1234 is a pure Windows user ...


    And ... under OMV exist no "automatic updates", OMV will daily check for updates and download them, but never installs them without user acceptance. You have to go to the WebGUI-Tab and do the upgrade with clicking ...


    Sc0rp