Beiträge von medikit

    Wir benutzen verschiedene WD HDD-Modelle, ich habe 2,5" WD5000BEVT. Daß es an WD liegen soll, glaube ich nicht, die haben nicht die Alleinschuld. Es ist wahrscheinlich eher eine Kombination aus den abgespeckten Möglichkeiten des NAS-Linux, des verwendeteten Kernels, den Treibern und WD.

    Tja, hm, ging nicht glatt, nicht schön. Wenn ich für 'nen Raidcontroller ein paar hundert Euros latzen würde, weil der mit "online capacity expansion" bzw. "online raid level migration" werben würde und das dann schief geht, würde ich von der Firma nichts mehr kaufen. Tja, und QNAP wirbt damit: Online RAID-Kapazitätserweiterung sowie Online RAID Level Migration. Gut, ein NAS ist kein Raidcontroller, aber ich find's Kacke.

    Alt.bin.z kannst Du nicht verwenden, es sie denn, es gibt eine Quellcode und kannst das selbst kompilieren. Nach dem wiki zu urteilen läuft auf auf Linux "nur" unter Wine. Das NAS hat einen bittorent-Client. Den kann man auch als "binary newsreader" (Selbstbeschreibung Alt.bin.z) verwenden.

    Reboot, aber Problem nicht weg. Es war noch nicht da, jetzt ist dmesg wieder voll von diesen Meldungen. Trotzdem Danke. Ich frag' den offiziellen Support.


    Update:
    iscsi deaktiviert, Meldungen weg. dmesg normal. Noch kein Wort vom Support.

    Das klappt. Raid 5 mit 3 Platten konfigurieren und 1 Platte als JBOD oder single disk. Die Datenträger nicht physikalisch zu trennen ist ein Risiko, daß man eingehen kann, aber immer noch ein Risiko. Physikalisch getrennte Sicherungen sind besser.

    Die Buffer size für was?


    Keine externen USB-Geräte, nie eins angeschlossen.


    Ich könnte iscsi auch noch abschalten, weil es nur mal auf Funktion getestet wurde


    Hier dmesg kurz nach dem Boot, sobald ich mit ssh draufkam:


    (disk 2 und 1 fehlen tatsächlich in der Ausgaben, das fängt hier an)

    dmesg > dmesg.txt



    Der erste Block ist der Anfang, nach ... das Ende. Dazwischen ändern sich nur die count(xx)- und #fd's(x) Nummern. Es steht nichts weiter drin, also, nichts was sonst in dmesg so auftaucht. EXT4 ohne write cache, nur ein paar Samba-Freigaben...

    dmesg behauptet sowas:
    ...
    Warning: dev (tty1) tty->count(13) != #fd's(12) in tty_release_dev
    Warning: dev (tty1) tty->count(13) != #fd's(12) in tty_release_dev
    Warning: dev (tty1) tty->count(11) != #fd's(10) in tty_release_dev
    Warning: dev (tty1) tty->count(9) != #fd's(8) in tty_release_dev
    Warning: dev (tty1) tty->count(9) != #fd's(8) in tty_release_dev
    Warning: dev (tty1) tty->count(8) != #fd's(7) in tty_release_dev
    ...
    und das ist nur ein kleiner Auszug. Kann jemand damit etwas anfangen? Ich komme damit sowas von überhaupt nicht klar. Im englischen Forum gibt's eine unbeantworteten Thread dazu. FW: 3.3.3 Build0928.

    Das Dateisysem EXT3 muß "eigentlich" nicht defragmentiert werden. Auch nach langer Nutzung sind oft nur wenige Prozent defragmentiert (einstelliger Prozenwert). Trotzdem gab's mal in der c't einen Artikel dazu, den finde ich aber grad' nicht.

    In der Doku findet sich für Dein Szenario (Migrieren von RAID 1 zu RAID 5) der Satz

    Zitat

    Alle Daten bleiben erhalten.


    Du wählst bei der Migration ja nur die neuen, zusätzlichen, unformatierten Platten aus. Auf denen werden die Daten gelöscht und darauf bezieht sich auch, was Du zitierst.

    Der Timeout und die Antwort kommen vom "Server", also QNAP. Bei Filezilla läßt sich der log-level hochdrehen, das könntest Du mal machen und nochmal 'nen Auszug posten. Was ich vermisse, ist AUTH TLS/AUTH SSL, die den Verschlüsselungsmodus anzeigen. Der Fehler könnte auch bei Fritz liegen, vielleicht hält die das Übertragen der Datei für einen Angriff und macht dem Port zu (reine Spekulation, hilft Dir aber vielleicht?). Die Ports für passives ftp sind wahrscheinlich korrekt weitergeleitet? In beide Richtungen?