Beiträge von Bionic

    Hallo,
    Wie ich schon sagte, so lange die Video-Dateien nicht zerstückelt werden, wie z.B. bei Raid 5 in einem Server, sondern komplett auf einer Platte landen, kann man diese Platten nur empfehlen.
    Bei Raid 5 o.ä. übernimmt halt die Serversoftware die Hauptaufgaben der Dateiverwaltung, da macht die Firmware einer Videofestplatte dann keinen Sinn mehr. Da sind dann NAS-Platten bestens geeignet.
    Ist es allerdings nur Raid 0 oder 1, dann landet die Datei wieder komplett auf einer Platte, da könnte das wieder Sinn machen.
    In diesen Festplatten soll auch eine spezielle verbesserte Fehlerbehebung für Videodaten integriert sein, dann halt aber keine für Server.


    Ich habe hier 2 Festplattenrekorder, die seit 6 und 8 Jahren mit diesen HDDs arbeiten und wie gesagt seit 4 Jahren eine 2TB WD, die zu 85% mit Videos befüllt meinen Mediaplayer via USB problemlos gefüttert hat.

    Patentieren natürlich durch QNAP, die, wie Du sagst, jetzt behaupten, 16 TB das ginge nicht. :P


    Mit der Geschwindigkeit bin ich zufrieden, der Hauptteil läuft sowieso mit und über 100mbit und reicht auch massig für den Dune.
    Und Spannungsverlust ist eh keine gute Sache für ein NAS, Netzteile und Elektronik überhaupt; aber ich lasse es mal lieber aus, auch weil zur Zeit keine USV dran ist. :cry:


    Eigentlich läuft die Kiste doch erstaunlich gut, grade wenn man Bedenkt, was da drinnen vorgeht. Einige Stromausfälle hat es auch schon überstanden! Na mal schauen, was als nächstes dann in ein paar Jahren kommt? 6, 8 oder 12 TB-Platten oder ein 7 Bay-Nas? :mrgreen:


    Aber ich bin froh, das dies jetzt erst mal gefunzt hat.


    Grüße
    Bionic

    So, sieht gut aus!
    Ich schätze, das war es?


    Großes Danke! an Euch beide, besonders an den "Doc", der sich seine großartige Idee patentieren lassen sollte. :thumb:


    Ich darf jetzt bloß nicht dem "roten Knopf" erliegen, der mich anstarrt sagt: "Drück mich!" :D
    (Eine Kapazitätserweiterung kann noch durchgeführt werden, wahrscheinlich noch ein paar wenige GB mehr. ;) )


    Der angelegte virtuelle Speicher hat sich wohl selbst aufgelöst.


    Eine Frage noch: Schreib‐Cache aktivieren (EXT4 delay allocation) aktivieren; hat ja eigentlich nur die Funktion, durch Verzögerung zu defragmentieren; oder doch aus lassen?

    Code
    [~] # dumpe2fs -h /dev/md0dumpe2fs 1.41.4 (27-Jan-2009)Filesystem volume name:   <none>Last mounted on:          /share/MD0_DATAFilesystem UUID:          58f957d4-fb6f-4abd-98a2-87cfc211901bFilesystem magic number:  0xEF53Filesystem revision #:    1 (dynamic)Filesystem features:      has_journal ext_attr resize_inode filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isizeFilesystem flags:         unsigned_directory_hashDefault mount options:    (none)Filesystem state:         cleanErrors behavior:          ContinueFilesystem OS type:       LinuxInode count:              732274688Block count:              2929087152Reserved block count:     131072Free blocks:              1210551127Free inodes:              732237807First block:              0Block size:               4096Fragment size:            4096Reserved GDT blocks:      325Blocks per group:         32768Fragments per group:      32768Inodes per group:         8192Inode blocks per group:   512RAID stride:              1Flex block group size:    16Filesystem created:       Sun May 18 13:13:17 2014Last mount time:          Wed Jun 25 03:08:56 2014Last write time:          Wed Jun 25 21:33:21 2014Mount count:              1Maximum mount count:      -1Last checked:             Wed Jun 25 00:29:04 2014Check interval:           0 (<none>)Reserved blocks uid:      0 (user admin)Reserved blocks gid:      0 (group administrators)First inode:              11Inode size:               256Required extra isize:     28Desired extra isize:      28Journal inode:            8Default directory hash:   half_md4Directory Hash Seed:      641abc53-246f-4306-a5a9-4497f9175babDirectory Magic Number:   0x514E4150Journal backup:           inode blocksJournal size:             128M


    Code
    [~] # storage_boot_init 2storage_boot_init 2 ...mdadm: /dev/md0 not identified in config file.mdadm: stopped /dev/md0mdadm: /dev/md0 has been started with 4 drives.storage_boot_init.c: Start raid device /dev/md0 successfullymd0 : active raid5 sda3[0] sdd3[3] sdc3[2] sdb3[1]md0 : active raid5 sda3[0] sdd3[3] sdc3[2] sdb3[1]md0 : active raid5 sda3[0] sdd3[3] sdc3[2] sdb3[1]md0 : active raid5 sda3[0] sdd3[3] sdc3[2] sdb3[1]storage_boot_init.c:     /dev/md0 is active.storage_boot_init.c: Check filesystem on /dev/md0.storage_boot_init.c: check_last_degrade_error...[~] #



    Na, das schaut doch jetzt besser aus, oder? ;)

    Code
    # tune2fs -j /dev/md0
    tune2fs 1.41.4 (27-Jan-2009)
    Creating journal inode: done
    This filesystem will be automatically checked every -1 mounts or
    0 days, whichever comes first.  Use tune2fs -c or -i to override.


    Komisch, ich habe mir grade die Anleitung von nestolea (siehe Link weiter vorne) noch mal angeschaut und wollte das grade vorschlagen, denn ich habe ja abgebrochen. Hätte aber eigentlich gedacht, daß dies nach mehrfachem reboot wieder aktiviert wird.


    soll ich jetzt mal rebooten?


    Edit: Ach, da ist er ja hinzugekommen und schreibt es selbst.
    Also doch ein Fehler von mir, weil nicht durch- besser gesagt: zu ende gedacht. _hurted:

    Code
    [~] # mdadm -D /dev/md0/dev/md0:        Version : 01.00.03  Creation Time : Sun May 18 13:12:25 2014     Raid Level : raid5     Array Size : 11716348608 (11173.58 GiB 11997.54 GB)  Used Dev Size : 3905449536 (3724.53 GiB 3999.18 GB)   Raid Devices : 4  Total Devices : 4Preferred Minor : 0    Persistence : Superblock is persistent  Intent Bitmap : Internal    Update Time : Wed Jun 25 21:09:31 2014          State : active Active Devices : 4Working Devices : 4 Failed Devices : 0  Spare Devices : 0         Layout : left-symmetric     Chunk Size : 64K           Name : 0           UUID : b9db3bc5:4969715f:081f259a:2d3cf5aa         Events : 46711    Number   Major   Minor   RaidDevice State       0       8        3        0      active sync   /dev/sda3       1       8       19        1      active sync   /dev/sdb3       2       8       35        2      active sync   /dev/sdc3       3       8       51        3      active sync   /dev/sdd3



    Hallo,


    Sorry, ich habe heute Morgen noch Deinen mount-Befehl eingegeben, weil ich das Ergebnis nicht abwarten konnte. :engel:
    mount /dev/md0 /share/MD0_DATA -t ext4
    Ergebnis sieht so aus:

    Du bist (auch) ein Held! :D


    Danke! :thumb:


    Wieder da.
    Ich hoffe, das hält erst mal. :oops:
    Ich starte die Erweiterung jetzt nochmals.


    Ach ja:


    Edit: Habe mir den Vorgang noch mal zu Gemüte geführt.
    Mit mount /dev/md0 /share/MD0_DATA -t ext4 -o ro habe ich praktisch das Raid also wieder geladen
    und dann den Speicher -als Auslagerungsdatei auf den Festplatten angelegt- erhöht. Richtig?
    Alternativ gäbe es dann also noch die Möglichkeit eines Versuchs mit einem USB-Stick?!
    Aber Vielleicht klappt es ja diesmal und die Idee macht Schule!


    Grüße

    Ich habe so gut wie keine Ahnung von Linux. Hab einfach mal free eingegeben:

    Code
    [~] # free
                  total         used         free       shared      buffers
      Mem:       255676       216672        39004            0         6340
     Swap:       530040         4332       525708
    Total:       785716       221004       564712
    [~] #


    Kapazität erweitern gibt es jetzt nicht mehr, weil das Raid entladen ist (aber wohl noch da?!).
    Es lässt sich natürlich auch nicht mehr prüfen.


    Edit: Ach ja, bei mount /dev/md0 kommt:

    Zitat

    [~] # mount /dev/md0
    mount: can't find /dev/md0 in /etc/fstab or /etc/mtab

    Hallo,


    Danke, das Du vorbeischaust. :thumb:


    Dateisystem ist ext4


    Code
    [~] # mdadm -D /dev/md0/dev/md0:        Version : 01.00.03  Creation Time : Sun May 18 13:12:25 2014     Raid Level : raid5     Array Size : 11716348608 (11173.58 GiB 11997.54 GB)  Used Dev Size : 3905449536 (3724.53 GiB 3999.18 GB)   Raid Devices : 4  Total Devices : 4Preferred Minor : 0    Persistence : Superblock is persistent  Intent Bitmap : Internal    Update Time : Tue Jun 24 22:30:18 2014          State : active Active Devices : 4Working Devices : 4 Failed Devices : 0  Spare Devices : 0         Layout : left-symmetric     Chunk Size : 64K           Name : 0           UUID : b9db3bc5:4969715f:081f259a:2d3cf5aa         Events : 39490    Number   Major   Minor   RaidDevice State       0       8        3        0      active sync   /dev/sda3       1       8       19        1      active sync   /dev/sdb3       2       8       35        2      active sync   /dev/sdc3       3       8       51        3      active sync   /dev/sdd3[~] #


    Code
    mount | grep /dev/md0 | awk '{print $5}'


    zeigt gar nichts an...


    bei

    Code
    # e2fsck -f /dev/md0

    kam

    Code
    Pass 1: Checking inodes, blocks, and sizesError allocating block bitmap (4): Memory allocation failede2fsck: aborted


    Code
    cat /proc/mdstat


    gibt mir folgendes aus:


    Grüße

    So, heute morgen hat das Nas die neue Platte dem Raid erfolgreich hinzugefügt, es läuft jetzt über alle 4 Platten, statt auf vorher 3.
    Dies hat also schon mal geklappt.
    Leider hat es die Erweiterung von ~ 8 GB auf 11176 GB nicht durchführen können:

    Zitat

    Server Name: QNAS
    IP Address: 192.168.0.10
    Date/Time: 23.06.2014 03:58:24
    Level: Error
    [RAID5 Disk Volume: Drive 1 2 3 4] Expanding Raid Device failed.


    auch das manuelle anstoßen, mit Abschalten sämtlicher Dienste und Neustart, hat nicht funktioniert,
    nach etwa anderthalb Stunden wird abgebrochen und wieder zurückgesetzt.

    Zitat

    Server Name: QNAS
    IP Address: 192.168.0.10
    Date/Time: 23.06.2014 13:51:28
    Level: Error
    [RAID5 Disk Volume: Drive 1 2 3 4] Raid Size Expansion failed.


    Jemand noch eine Idee?
    Haben das andere noch lösen können?
    Scheint hier ein ähnliches Problem zu sein: klick


    Grüße


    -------------------------
    Edit:


    Noch ein Problem:
    Ein Bekannter kam hinzu und versuchte es mal nach dieser Anleitung, via SSH/Putty.
    Leider funktionierte der Befehl lsof +f -- /dev/md0 nicht und e2fsck -f /dev/md0 wurde auch nicht ganz ausgeführt (Fehler wie hier - zu wenig Speicher?). Ich habe das dann abgebrochen. Wir kamen bis zum Punkt mdadm --grow /dev/md0 --size max, den das System ohne e2fsck-Check aber nicht ausführen wollte.
    Das Raid ist aber seitdem ständig Entladen (wegen umount /dev/md0 ?), auch nach Neustart. Wie kann ich das wieder mounten?


    Grüße

    Habe neulich auch gesucht und dann mal Paragon ExtFS for Windows probiert, denn von ext2fsd war die letzte Version von 2011. :-/
    Hatte die Festplatten mit ext4 am NAS formatiert und die werden unter Win7 64 im Dock via usb und esata angezeigt.
    Mein Dune (Mediaplayer basierend auf Linux) kann mit den Backup-Platten allerdings gar nichts anfangen, eigenartig! (vielleicht mag er nur ext3?)


    Grüße

    Weiter geht's.


    Gestern die Austauschplatte bekommen und in den 4. Schacht eingesetzt.
    Formatiert und über Nacht nach defekten Blöcken suchen lassen.
    Werde jetzt die Festplatte dem Raid 5 hinzufügen. Vorgang läuft, wird sicher 1-2 Tage dauern, wenn es klappt.
    Drückt mir die Daumen!


    ---Edit---


    Zitat von "Bionic"

    Vorgang läuft, wird sicher 1-2 Tage dauern, wenn es klappt.


    wohl eher 5 Tage... :schnarch: :mrgreen:

    OK, scheint weiter keine besseren Optionen zu geben.


    Habe das Abschalten der Festplatten in den Standbymodus jedoch wieder hin bekommen.
    Ein paar mal die Funktion
    Bereitschaftsmodus der Festplatte aktivieren, wenn kein Zugriff innerhalb des angegebenen Zeitraums erfolgt:
    ein-ausgeschaltet und die Zeiten mehrfach verändert (jetzt 10 Minuten),
    außerdem im Microsoft-Netzwerkdienst, den Lokaler Master Browser ein paar mal deaktiviert
    (ist jetzt aus - allerdings konnte ich mit ihm das NAS auf meinen PCs unter Windows besser sichtbar machen und auch finden)
    und den Punkt WINS-Server aktivieren wieder ausgeschaltet.

    Irgendwie funktioniert es seitdem, obwohl ich das alles schon mal durchprobiert hatte. Na gut. Ich hoffe, es bleibt jetzt so!
    Zumindest spielt die hohe Auslastung des Speicherplatzes anscheinend diesmal keine Rolle.

    Ich habe grade erst eine ORICO 6518sus3 gekauft, damit läuft alles wie geschmiert.
    Advanced-Format-Festplatten mit 4K-Sektoren, Spin-down, esata mit 50MB/s vom NAS auf HDD (mit ext4 via NAS formatiert) schreiben.
    Keine Hitzeprobleme.