Beiträge von joernahlers

    Ich hatte grade eine Stunde mit einem Support Mitarbeiter und einem QNAP Entwickler eine Teamviewer Session. Beiden konnte ich das Problem darstellen, aber eine Lösung konnte nicht gefunden werden. Es ist ein Fehler der in dem nächsten Release behoben wird.

    Hallo die beiden NAS laufen mit FW 4.1.4 und das ist alles normal mit busybox.


    Leider gibt es kein iotop damit ich mir ausgeben lassen kann welche Prozesse die Last auf der Partition verursachen aber hier die Ausgabe von iostat

    Code
    [/mnt/HDA_ROOT] # iostat -d md9
          md9
      kps tps svc_t
      488 122   0.0


    Ich gehe davon aus, dass rsync das Problem verursacht. Rsync hat bereits zuvor eine log-Datei geschrieben die den Speicherplatz zum überlaufen gebracht hat. Nach dem Neustart konnte daher das Volume nicht gemountet werden. Dieser Fehler konnte durch das Löschen der Log-Dateien gelöst werden. Nach dem Neustart war alles wieder in Ordnung. Rsync habe ich wieder gestartet und die log Datei wurde wieder größer. Damit das vorherige Problem nicht wieder auftritt habe ich die Log-Datei gelöscht. Damit wurde der Speicherplatz freigegeben, aber dennoch ist die Festplattenauslastung weiter angestiegen. Ich gehe nun davon aus, dass rsync einfach auch ohne Datei an der Speicherposition weiter auf die Partition schreibt, an der ich die Datei gelöscht habe.

    Zitat von "Cerberus"


    check doch mal die untergeordneten Verzeichnisse ...
    irgend eines davon ist so groß, das es dir die Probleme macht ...


    Es gibt nicht mehr hier noch die Ausgabe des Verbrauchs mit Dateien


    Leider erreicht man bei QNAP über den Chal als auch über Hotline keinen verantwortlichen. Naja dann muss ich mal gucken wie es sich entwickelt.

    Vielleicht macht folgende Ausgabe die Sache verständlicher:

    Code
    [/mnt/HDA_ROOT] # du -H .du: WARNING: use --si, not -H; the meaning of the -H option will soonchange to be the same as that of --dereference-args (-D)455k    ./.qpkg/QNAP_Diagnostic_Tool459k    ./.qpkg1.2M    ./.driver4.1k    ./.cups/lpd4.1k    ./.cups/smb/64.1k    ./.cups/smb/24.1k    ./.cups/smb/44.1k    ./.cups/smb/34.1k    ./.cups/smb/74.1k    ./.cups/smb/529k     ./.cups/smb4.1k    ./.cups/cups/tmp8.2k    ./.cups/cups46k     ./.cups89M     ./update_pkg21k     ./.config/.qos_config/login8.2k    ./.config/.qos_config/users/scanner8.2k    ./.config/.qos_config/users/bilddb4.1k    ./.config/.qos_config/users/admin25k     ./.config/.qos_config/users50k     ./.config/.qos_config119k    ./.config/emap17k     ./.config/qsync201k    ./.config/storage_usage_history13k     ./.config/ssmtp4.1k    ./.config/torrent/torrent4.1k    ./.config/torrent/downloadinfo13k     ./.config/torrent29k     ./.config/ups25k     ./.config/stunnel21k     ./.config/ssh8.2k    ./.config/ntp4.1k    ./.config/mtp4.1k    ./.config/.qsys8.2k    ./.config/vaultServices50k     ./.config/openvpn/keys54k     ./.config/openvpn4.1k    ./.config/license/.req4.1k    ./.config/license/.lc4.1k    ./.config/license/.gnupg21k     ./.config/license13k     ./.config/openldap8.2k    ./.config/php.d4.1k    ./.config/.hd_info33k     ./.config/logo689k    ./.config/rssdoc37k     ./.config/lvm/archive13k     ./.config/lvm/backup54k     ./.config/lvm87k     ./.config/apache/extra62k     ./.config/apache/original/extra82k     ./.config/apache/original279k    ./.config/apache4.1k    ./.config/lunporter8.2k    ./.config/symform4.1k    ./.config/cups/ppd25k     ./.config/cups3.2M    ./.config25k     ./.logs/qsync4.1k    ./.logs/.qsync_log_queue4.1k    ./.logs/rsync1.4M    ./.logs17k     ./lost+found4.1k    ./.inited2.1M    ./ssl_lib98M     .


    Dazu die disk free Ausgabe:

    Code
    [/mnt/HDA_ROOT] # df
    Filesystem                Size      Used Available Use% Mounted on
    none                    200.0M    137.0M     63.0M  68% /
    devtmpfs                  1.9G      4.0k      1.9G   0% /dev
    tmpfs                    64.0M      2.3M     61.7M   4% /tmp
    tmpfs                     1.9G         0      1.9G   0% /dev/shm
    /dev/md9                509.5M    509.5M         0 100% /mnt/HDA_ROOT
    /dev/mapper/cachedev1    18.9T     11.2T      7.7T  59% /share/CACHEDEV1_DATA
    /dev/md13               371.0M    335.5M     35.5M  90% /mnt/ext


    Scheinbar hat QNAP in der Firmware wieder Mist gebaut, was leider häufiger vorkommt. Aber es muss irgendwo die Möglichkeit geben das logging zu unterbinden.

    Zitat von "Cerberus"

    PS: hat du rebootet?


    Das werde ich erst machen, nachdem die Sicherung durchgelaufen ist.


    Hier die Ausgabe für das Verzeichnis /mnt/HDA_ROOT/.logs/rsync/


    Code
    # ls -al
    drwxr-xr-x    2 admin    administ      4096 Jun 25 08:40 ./
    drwxr-xr-x    5 admin    administ      4096 Jun 25 03:30 ../
    -rw-r--r--    1 admin    administ         0 Jun 24 09:13 rsync-err-Schedule0
    -rw-r--r--    1 admin    administ         0 Jun 24 09:13 rsync-tmp-Schedule0

    Ok das script erzeugt eine leere info.txt . Das Problem sind auch nicht die vorhandenen Dateien. Die Verbrauchen auf der gesamten Partition nur ca. 100MB. Die Partition wird leider auf andere Weise gefüllt. Zudem ist das Verhalten der Replication falsch. Wieso werden die Standard-Ausgaben von rsync geloggt, dies muss deaktiviert werden. Das Problem wird nicht auftreten wenn mach ein paar Tausend Dateien repliziert, aber bei mehren Millionen läuft der Speicherplatz zwangsläufig über.

    Zitat von "Cerberus"

    as sagt die Ausgabe von df?


    Zitat von "joernahlers"

    Die Auslastung der Partition liegt bei 100%, obwohl 500MB zur Verfügung stehen.

    Code
    /dev/md9                509.5M    509.5M         0 100% /mnt/HDA_ROOT


    Die logs liegen unter /mnt/HDA_ROOT/.logs/rsync. Ich habe/hatte dort folgende Dateien:

    Code
    rsync-err-Schedule0
    rsync-out-Schedule0
    rsync-tmp-Schedule0


    Problematisch war die rsync-out-Schedule0 welche unbegrenzt wächst. Grstern nach einem Neustart konnte daher das Volume nicht gemountet werden. Nachdem das NAS wieder lief und die Replication gestartet haben konnte ich feststellen, dass die Datei wieder wächst. Dann habe ich die Deiei einfach gelöscht. Naja heute morgen war die Datei immer noch nicht vorhaben, aber die Partition voll. Nun werde ich aber auch das NAS nicht neustarten, ohne dass die Replication durchgelaufen ist. Der Ausfall des Gerätes wäre tragisch.

    Ich denke ich habe das Problem noch nicht richtig geschildert. Die Partition wird auch weiter gefüllt, obwohl ich die Dateien gelöscht habe.


    Vielleicht hilft dies weiter:


    Der Speicherplatz verbrauch der vorhandenen Dateien ist ca. 100MB

    Code
    du -H -s HDA_ROOT/du: WARNING: use --si, not -H; the meaning of the -H option will soonchange to be the same as that of --dereference-args (-D)98M     HDA_ROOT/


    Die Auslastung der Partition liegt bei 100%, obwohl 500MB zur Verfügung stehen.

    Code
    /dev/md9                509.5M    509.5M         0 100% /mnt/HDA_ROOT

    Hallo,


    wir haben zwei TS-1270U und replizieren die Daten von dem einen NAS zu dem Anderen per NAS-to-NAS Replication. Dabei wird die /HDA_ROOT/ Partition mit log-Dateien von rsync gefüllt, bis diese überläuft. Dies ist nicht tragisch, aber wenn das NAS neustartet wird das Volume nicht mehr gemountet.
    Auch nachdem ich die log-Dateien gelöscht habe wird wie Partition weiter befüllt. In die Datei wird die Standard-Ausgabe von rsync gespeichert und ist damit auch wenig sinnvoll.
    Zu replizieren sind knapp 7 Mio. Dateien mit einer Größe von ca. 12 TB.


    Ich habe bereits mehrere Tickets bei QNAP offen, erhalte aber keine Antworten. Dies ist auch nicht der einzige Fehler, aber der gravierendste.

    Hallo,


    ich habe am Wochenende ein Downgrade auf die Firmware 4.0.5 auf anraten des Supports gemacht.Nun ist bei uns das Problem, dass nicht nur die Fehler erhalten bleiben, außerdem die Config des RTRR-Server kaputt ist.


    Der RAM sieht gut aus


    used:3873800 free:64820 buffers:601436


    Swap wird nicht verwendet.

    Hallo, ich habe zwei ts-1270U, wobei das eine NAS auf das andere repliziert wird. Wegen einem Bug in der Firmware 4.0.5 konnte ich kein RTRR Server aktivieren und habe das Update auf die Firmware 4.1 auf deinen Systemen durchgeführt. Beide verwenden ein Raid5 und das Haupt-NAS hat noch einen 512GB SSD Cache. Der User-Zugriff erfolgt ausschließlich auf das Haupt-NAS. Der lesende Zugriff funktioniert problemlos, nur bei schreibenden Vorgängen mit vielen Dateien kommt es zu Problemen bei der ramdisk mit folgender Fehlermeldung:


    Code
    Server Name: ol-fbbug-nas05
     IP Address: 
     Date/Time: 2014/02/21 17:57:57
     Level:  Error
     The system is unable to save your settings (file = [/share/HDA_DATA/.versioning/CACHEDEV1_DATA/homes/jo1042/SDT9322.tmp.d/versioning.config], section = [Versioning], field = [LockID], value = [1393001877-8514]) due to insufficient ramdisk space. If restarting the server does not solve the problem please contact support for further assistance.


    Ich habe bereist den SSD Cache deaktiviert, dies hilft leider nichts. Ich kann das Webinterface nicht mehr aufrufen. Kurzzeitig hilf es das NAS neuzustarten, sobald wieder große Schreibvorgänge erfolgen gibt es die Fehlermeldungen. Gibt es Lösungen für diese Problematik? In alles Fehlermeldungen betrifft es die Dateien versioning.config in unterschiedlichsten Ordnern, kann es sein, dass eine Versionierung durchgeführt wird? Ist es sinnvoll und hilfreich diese zu deaktivieren?