Hi longint,
hat es funktioniert? Gib mal bitte Feedback, um das Thema abzuschließen.
Linuxnutzer
Hi longint,
hat es funktioniert? Gib mal bitte Feedback, um das Thema abzuschließen.
Linuxnutzer
Zitat von "longint"
Brauche ich für die : Version überhaupt den rsyncd?
Nein.
Man muß für den rsyncd-mode aber die /etc/rsyncd.conf einrichten, was auf dem NAS anscheinend automatisch erledigt wird. Dort sind alle shares als Module eingetragen, d.h. in Verzeichnisse außerhalb der Shares kann nicht ge-rsynct werden.
Desweiteren läuft der rsync-Prozeß per default in einer chroot-Umgebung mit dem share-folder als root. Das bringt zusätzliche Sicherheit, daß außerhalb des shares nichts geschrieben werden kann. Allerdings hat rsync dadurch keinen Zugriff auf /etc/passwd und /etc/groups, d.h. user und group mapping funktioniert nicht, falls gleiche user-/groupnamen auf unterschiedliche IDs gemapped sind, d.h. praktisch ist immer die Option --numeric-ids aktiv, falls owner/group gesichert werden soll.
Doch, doch. Ein : ist remote shell mode (ssh); zwei :: ist rsyncd-mode (http://www.samba.org/ftp/rsync/rsync.html - CONNECTING TO AN RSYNC DAEMON), das würde etwa so aussehen: 'rsync -av SRC qnap::/SHARENAME/...' evtl. 'rsync -av SRC Rsyncuser@qnap::/SHARENAME/...'. Rsyncuser und Passwort muß man erst konfigurieren, genau wie die Option, dass es erlaubt ist auf das NAS zu kopieren. Ich hab es nicht mehr genau im Kopf, aber wahrscheinlich findet man die Optionen unter Backup oder so.
Bei mir hat sich die Datenrate mit dem rsync-mode ca. um den Faktor 2,5 erhöht gegenüber sshd-mode.
Ich vermute mal, daß Du rsync im sshd-mode ausführst. Vielleicht kannst Du mal die Kommandozeile posten. Besser wäre der rsyncd-mode.
sshd-mode:
rsync verbindet sich mit dem sshd auf dem NAS und ruft auf dem NAS rsync auf, welches die Daten schreibt. sshd und rsync belasten die CPU, vorallem sshd wegen der verschlüsselten Übertragung.
rsyncd-mode:
rsync verbindet sich mit dem rsyncd auf dem NAS. rsyncd muß vorher aktiviert und eingerichtet werden im Admin-GUI. Weniger CPU-Last, da die Verschlüsselung wegfällt -> höhere Datenrate.
smb-mount-mode:
rsync läuft nur lokal auf dem PC, welcher genug CPU-Leistung hat. NAS schreibt nur Daten -> geringe CPU-Last.
rsync ist ja eher ein Programm, welches für Backups über niedrigratige Verbindungen konzipiert wurde, d.h. die zu übertragende Datenmenge wird gering gehalten. rsync analysiert jedes File und überträgt nur unterschiedliche Blöcke und prüft die korrekte Übertragung mittels Checksummen. Das ist natürlich rechenaufwändig, aber sicher!
Linuxnutzer
Wahrscheinlich ist es etwas nicht ganz einfach, eine kompatible Platte zu finden. Bei mir liefen mehrere Trekstor Pocket l.u. 500GByte so leidlich mit sporadischen Abbrüchen. Bin jetzt auf Seagate Portable Expansion 500GByte umgestiegen und hatte noch nie irgendwelche Probleme und das ohne externe Stromversorgung nur mit einem Y-Kabel. Auch eine zweite Platte, die ich letzte Woche angeschlossen habe läuft ohne Probleme. Habe mehrere Hundert GByte am Stück kopiert. Siehe aber: http://forum.qnapclub.de/viewtopic.php?f=12&t=4897#p55303. Die Platte kann ich sehr empfehlen (Bin nicht mit Seagate verbandelt und bekomme auch kein Geld oder andere Vergünstigungen für den Beitrag hier:)
Linuxnutzer
Ja, das geht, wenn man das cups-package über ipkg installiert (die von Qnap bereitgestellte Drucklösung habe ich allerdings nicht ausprobiert, vielleicht geht's auch damit). Bei mir war noch ein wenig Handarbeit nötig, damit der cups-daemon automatisch gestartet und beendet wird. Dann kann man cups bequem im Browser (http://SERVERNAME:631) einrichten. Sollte der Netzwerkdrucker postscriptfähig sein, dann braucht man lediglich noch ein ppd-File bereitzustellen, das war's. Ansonsten müssen noch Treiber installiert werden, was ich allerdings nicht ausprobiert habe.
Linuxnutzer
Zitat von "MinchenXXL"Hi,
kann man diese Fehlenden Dateien nachinstallieren auf die TS439 Pro II ?
/lib/libc.so.6: version `GLIBC_2.7' not found
/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11
Anhand Deiner Fragestellung nehme ich mal an, daß Du mit Linux nicht vertraut bist. Daher lautet meine Antwort:
NEIN!!!
Linuxnutzer
In Crontab-Scripten immer mit kompletten Pfaden arbeiten. Ich nehme an, daß der Pfad zu "screen" nicht gefunden wurde, da beim Aufruf des Scripts die PATH-Variable nicht gesetzt wird. Allerdings wird "screen" auch wirklich nicht benötigt.
Linuxnutzer
Also ohne Aufschrauben komme ich an die Info anscheinend nicht ran. Hab den halben sys-Pfad durchsucht, aber nicht viel zu Tage gefördert. Die Trekstor hat nen Eintrag "JMicron" als vendor o.ä. Über die Seagate bekomme ich nichts raus. Es scheint aber durchaus Unterschiede zu geben, nur ist es wahrscheinlich schwer möglich, vor dem Kauf etwas über den Controller-Typ herauszufinden, der vielleicht auch innerhalb der Serie nicht der gleiche sein muß.
Linuxnutzer
Zitat von "qnutbert"Habe heute mal meine USB box geöffnet und nach dem Chip gesehen: ist ein JMicron JM20339 High Speed USB to SATA Bridge.
Der bereitet wohl auch einigen Besitzern von Synology NAS Probleme...
Welche Chips sind in Euren USB Gehäusen drin?
Gruß, qnutbert
Ich schau mal nach. Bisher hatte ich 2 Trekstor Pocket l.u. 500GByte. Da gab es sporadische Abbrüche und für das erste Backup hab ich mehrere Anläufe benötigt. Wenn ich mich richtig erinnere, dann ist da ein JMicron drin. Jetzt ist eine davon defekt und ich habe als Ersatz eine Seagate Portable Expansion 500GByte gekauft, die läuft bisher super (siehe aber http://forum.qnapclub.de/viewtopic.php?f=12&t=4897#p55303). Auch das erste Backup (ca. 350GByte) auf Anhieb fehlerfrei, muß mal nach dem Chip schauen.
Linuxnutzer
Lest mal:
http://forum.qnapclub.de/viewtopic.php?f=27&t=4114&start=0
http://forum.qnapclub.de/viewtopic.php?f=166&t=8127&start=0
Es gibt sehr sehr viele Ursachen, wenn das Backup abbricht. Da kann man nicht raten. Die einzige Möglichkeit wenigstens einen Anhaltspunkt zu bekommen, ist die dmesg-Ausgabe gleich nach dem Abbruch zu kopieren und an den Post anzuhängen.
Zitat von "qnutbert"Hallo,
Interessant finde ich in diesem Thread die These, dass es ein thermisches Problem sein könnte - werde dem wohl mal nachgehen...
Gruß,
qnutbert
Das vermute ich auch schon länger, hatte letzte Woche mal ein abgebrochenes Backup und da war es recht warm im Zimmer (28°C). Ich lasse mir aber jetzt immer Mails schicken, wenn das Backup nicht geklappt hat, so daß ich schnell reagieren kann.
Linuxnutzer
Hi,
mir ist auch vor 2 Wochen eine USB-Backupplatte kaputt gegangen. Beim täglichen inkrementellen Backup gab es eigentlich nie Probleme, zu Beginn beim ersten Backup, als ca. 350GByte kopiert werden mußten, brach der Kopiervorgang mehrmals ab. Jetzt hab ich eine neue Platte (Seagate Expansion Portable) und bis auf anfängliche Hürden mit dem Spin-Down (siehe http://forum.qnapclub.de/viewtopic.php?f=12&t=4897#p55303) gab es bisher noch keinen einzigen Abbruch, auch beim ersten Backup nicht, vielleicht zieht sie ja weniger Strom vom USB-Port
Was ich aber als Problem empfinde, ist der etwas laxe Umgang der Firmware mit Dateisystemfehlern. Als meine Platte langsam den Geist aufgab, habe ich es lange nicht bemerkt, bis dann das Backup abbrach. Auf die Platte schreiben ging noch, nur beim Löschen einiger Files gab es dann schwerwiegende Fehler. In der dmesg-Ausgabe stand dann auch sowas wie "mounted with errors", aber nichts im Log oder gar E-Mail-Benachrichtigung.
Liinuxnutzer
Hi,
was hast Du denn für einen Drucker?
Ich betreibe im lokalen Netzwerk einen Samsung ML-2851ND und drucke auch vom NAS. Dafür muß man Optware installieren und kann dann cups als ipkg installieren. Cups hat eine komfortable Web-Oberfläche zum Administrieren und Verwalten (Standard-Port 631). Hast Du einen postscriptfähigen Drucker (wie ich), dann bist Du fein raus, dann brauchst Du Dir nur das PPD-File besorgen (von CD oder von http://www.openprinting.org/printers) und bei der Einrichtung des Drucker angeben -> fertig:) Ansonsten brauchst Du nen Treiber. Die Gutenprint-Treiber gibt's als ipkg. Aber ob es letztendlich funktioniert, hängt von Deinem Drucker ab.
Mit VPN kenne ich mich nicht aus, kann Dir daher nicht sagen, ob cups über VPN erreichbar ist.
Linuxnutzer
Hi,
nachdem bei mir eine externe Platte für Backups den Geist aufgegeben hat und ich es erst nach ein paar Tagen gemerkt habe, habe ich mir ein Script gebastelt (Vorlage: http://forum.qnap.com/viewtopi…hot+mail&start=50#p104819), welches mir Mails an meine Benachrichtigungs-Mailadresse schickt über Erfolg oder Mißerfolg der Backups des aktuellen Tages.
Wichtig: E-Mail-Benachrichtigung muß über das Web-Gui konfiguriert sein.
#!/bin/bash
# Config section
MAIL_TO="max.mustermann@web.de"
MAIL_HEADER_TO="Max Mustermann <max.mustermann@web.de>"
MAIL_HEADER_FROM="Max Mustermann <max.mustermann@web.de>"
MAIL_HEADER_SUBJECT="Backup Log"
MAIL_HEADER_SUBJECT_ERROR="Backup ERROR!"
# Uncomment to suppress log mails without errors
# SEND_MAIL_ONLY_ON_ERROR=1
# Do not edit below this line
# Header Stuff
LOG_FILE="/opt/var/log/rsnapshot"
TMP_LOG_FILE="/tmp/rsnapshot_log.log"
MAIL_FILE="/tmp/rsnapshot_log.mail"
# Program
MAIL="/usr/sbin/ssmtp"
# Foramt dates
DATE=`date +"%d/%b/%Y"`
PRINT_DATE=`date +"%d.%m.%Y"`
SUBJECT_DATE=`date +"%F"`
# No logs today
if [ `fgrep $DATE $LOG_FILE -c` -eq 0 ]; then
exit 0
fi
# Extract Todays Log ( format 30/Mar/2006 )
fgrep $DATE $LOG_FILE > $TMP_LOG_FILE
# Detect errors
if [ `fgrep "ERROR" $TMP_LOG_FILE -c` -gt 0 ]; then
MAIL_HEADER_SUBJECT=$MAIL_HEADER_SUBJECT_ERROR
ERROR=1
else
if [ -n "$SEND_MAIL_ONLY_ON_ERROR" ]; then
# Suppress log mails without errors
exit 0
fi
fi
{
echo "TO: $MAIL_HEADER_TO"
echo "FROM: $MAIL_HEADER_FROM"
echo "SUBJECT: $MAIL_HEADER_SUBJECT $SUBJECT_DATE"
echo ""
echo "Backup Report on $PRINT_DATE"
egrep "completed|ERROR" $TMP_LOG_FILE
echo ""
echo "Disk Usage:"
df -h
if [ -n "$ERROR" ]; then
echo ""
echo "Full Log:"
echo ""
cat $TMP_LOG_FILE
echo ""
echo "Dmesg output:"
dmesg
fi
} > $MAIL_FILE
# Send Mail
$MAIL $MAIL_TO < $MAIL_FILE
# Remove Temporary Files
rm -rf $MAIL_FILE $TMP_LOG_FILE
Alles anzeigen
Dieses Script sollte dann per cron am gleichen Tage wie die Backups aufgerufen werden. Vorher noch die Mailadressen editieren
Linuxnutzer
Hi,
habe mich mit dem Problem ein wenig beschäftigt, da ich mir selbst eine Seagate Platte mit Standby zugelegt habe. Für die meisten Nutzer gibt es nur eine Lösung -> Die neueste Firmware zu installieren. Ab v3.2.5 0409 wird Kernel 2.6.30.6 verwendet. Alles ab Kernel 2.6.24 ist ok. Ansonsten kann man solche Platten nicht so ohne weiteres verwenden, da es u.U. zu Filesystemfehlern und Datenverlust kommen kann!!!! Siehe http://www.mail-archive.com/li…ceforge.net/msg52993.html oder http://www.nslu2-linux.org/wik…pinDownOnSeagateFreeAgent), dort sind Workarounds beschrieben. Es muß ein Attribut im sys-filesystem gesetzt werden, damit der Kernel die Platte weckt und so lange wartet.
Bei meiner TS119 hab ich aber 2.6.22.18 und wollte nicht updaten. Da udev-rules nicht so einfach möglich sind (siehe http://forum.qnapclub.de/viewtopic.php?f=33&t=3882#p22889) aber meine Platten immer am NAS hängen, hab ich mich für ein Script entschieden, das beim NAS-Start ausgeführt wird und zu Sicherheit noch mal per Cron vor dem Backup.
#! /bin/bash
EXT_DEVS="sdt sdi"
for DEV in $EXT_DEVS; do
if [ -e /sys/block/$DEV/device/scsi_disk*/allow_restart ]; then.
echo 1 > /sys/block/$DEV/device/scsi_disk*/allow_restart
fi
done
Alles anzeigen
Die Devices (EXT_DEVS im Script) kann man mit "ls -l /share/USBDisk*" ermitteln (Ziffern weglassen), wenn alle Platten gesteckt sind. Bei mir sind das:
/share/USBDisk1 -> external/sdt1
/share/USBDisk2 -> external/sdi1
Bei Eingabe von "cat /sys/block/sdt/device/scsi_disk*/allow_restart" oder "cat /sys/block/sdi/device/scsi_disk*/allow_restart" sollte nun eine 1 ausgegeben werden.
Linuxnutzer
Natürlich ist auf dem NAS ein fsck, nur nicht der "Wrapper", der dann die verschiedensten Programme aufruft. Ext2/3/4 prüft man mit e2fsck, z.B. erst mal mit "e2fsck -p -C 0 /dev/sdXX" (XX für das jeweilige device ersetzen).
Ich hatte auch vor ein paar Tagen eine Meldung über Fehler beim Mounten einer USB-Platte. Schien sich aber normal zu verhalten, nur als ich ein Verzeichnis löschen wollte, ging der Ärger los, Abbruch, Lesefehler im dmesg-output. e2fsck brach bei 75% ab. Da ist wohl die Platte im Eimer
Also ich würde eine Platte mit plötzlich auftretenden Fehlern erst mal testen bevor ich sie neu aufsetze.
Linuxnutzer
Zitat von "ColaMan"Alles anzeigenHallo alle Zusammen!
Kannst du vielleicht den selben test nochmal machen, aber die Platte bitte NICHT auf NTFS sondern auf EXT3 formatieren?!
NTFS kann Linux nur LESEN nicht SCHREIBEN! (ODER hat MS schon die Codeschnipsel zum Schreibverfahren von NTFS rausgerückt?!) Vielleicht kommen auch daher diese Fehlermeldungen ....
Liebe Grüße
Marcel
Die Fehlermeldungen kommen aber vom SCSI-Subsystem, welches noch unterhalb der Filesystemebene liegt. Daher kommen eher Hardware (Platte/Controller/Kabel etc.) oder Kerneltreiber in Frage.
QNAP hat, soweit ich weis, einen kommerziellen NTFS-Treiber (Paragon?) installiert (Lizenzgebühren trägt der Kunde ). Der ist sicher nicht experimentell, da der Firma die NTFS-Specs ja vorliegen.
Linuxnutzer
Zitat von "ukottig"Alles anzeigenHi,
tja, es hat zwar lange gut gegangen, aber jetzt habe ich wieder das gleiche Problem, das Backup bricht einfach ab.
Hier nun die Ausgabe von dmesg: (direkt nach frisch gestartetem Server)
CodeAlles anzeigenn-ehci orion-ehci.0: Marvell Orion EHCI orion-ehci orion-ehci.0: new USB bus registered, assigned bus number 1 orion-ehci orion-ehci.0: irq 19, io mem 0xf1050000 orion-ehci orion-ehci.0: USB 2.0 started, EHCI 1.00 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver uhci_hcd: USB Universal Host Controller Interface driver mice: PS/2 mouse device common for all mice Clear RTC Alarm interrupt. rtc-s35390a 0-0030: rtc core: registered rtc-s35390a as rtc0 Orion Watchdog Timer: Initial timeout 21 sec md: linear personality registered for level -1 md: raid0 personality registered for level 0 md: raid1 personality registered for level 1 md: raid10 personality registered for level 10 md: raid6 personality registered for level 6 md: raid5 personality registered for level 5 md: raid4 personality registered for level 4 device-mapper: ioctl: 4.14.0-ioctl (2008-04-23) initialised: dm-devel@redhat.com mv_xor_shared mv_xor_shared.0: Marvell shared XOR driver mv_xor_shared mv_xor_shared.1: Marvell shared XOR driver mv_xor mv_xor.0: Marvell XOR: ( xor cpy ) mv_xor mv_xor.1: Marvell XOR: ( xor fill cpy ) mv_xor mv_xor.2: Marvell XOR: ( xor cpy ) mv_xor mv_xor.3: Marvell XOR: ( xor fill cpy ) TCP cubic registered NET: Registered protocol family 17 NET: Registered protocol family 5 RPC: Registered udp transport module. RPC: Registered tcp transport module. Clear RTC Alarm interrupt. rtc-s35390a 0-0030: setting system clock to 2010-06-05 20:40:54 UTC (1275770454) md: Waiting for all devices to be available before autodetect md: If you don't use raid, use raid=noautodetect usb 1-1: new high speed USB device using orion-ehci and address 2 md: Autodetecting RAID arrays. md: Scanned 0 and added 0 devices. md: autorun ... md: ... autorun DONE. RAMDISK: gzip image found at block 0 VFS: Mounted root (ext2 filesystem) on device 1:0. Freeing init memory: 124K Clear RTC Alarm interrupt. Intergrated Sata device found IRQ 21/stat_mv: IRQF_DISABLED is not guaranteed on shared IRQs Spin up ...(0:0) Spin up ...(0:1) Spin up all... [0 0]: Waiting for channel initialization. [0 1]: Waiting for channel initialization. scsi0 : Marvell SCSI to SATA adapter usb 1-1: configuration #1 chosen from 1 choice hub 1-1:1.0: USB hub found hub 1-1:1.0: 4 ports detected scsi1 : Marvell SCSI to SATA adapter usb 1-1.1: new high speed USB device using orion-ehci and address 3 usb 1-1.1: configuration #1 chosen from 1 choice ENABLE_WRITE_CACHE (current: enabled). scsi 0:0:0:0: Direct-Access SAMSUNG HD103UJ 1AA0 PQ: 0 ANSI: 3 Check proc_name[mvSata]. Check proc_name[mvSata]. sd 0:0:0:0: [sda] 1953525168 512-byte hardware sectors: (1.00 TB/931 GiB) sd 0:0:0:0: Attached scsi generic sg0 type 0 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA sda: sda1 sda2 sda3 sda4 sd 0:0:0:0: [sda] Attached SCSI disk Initializing USB Mass Storage driver... 1.orion-ehci.0 2.1.1 Using EHCI controller. PORT = [8] scsi8 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 3 usb-storage: waiting for device to settle before scanning usbcore: registered new interface driver usb-storage USB Mass Storage support registered. qnap_usb: create proc systemp successfully qnap_usb: create proc systemp successfully scsi 8:0:0:0: Direct-Access Freecom Mobile Drive XXS PQ: 0 ANSI: 2 CCS sd 8:0:0:0: Attached scsi generic sg8 type 0 usb-storage: device scan complete sd 8:0:0:0: [sdi] 488397168 512-byte hardware sectors: (250 GB/232 GiB) sd 8:0:0:0: [sdi] Assuming drive cache: write through sd 8:0:0:0: [sdi] Assuming drive cache: write through sdi: sdi1 sd 8:0:0:0: [sdi] Attached SCSI disk kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with writeback data mode. md: md9 stopped. md: bind<sda1> raid1: raid set md9 active with 1 out of 1 mirrors md9: bitmap initialized from disk: read 5/5 pages, set 29 bits created bitmap (65 pages) for device md9 md9: unknown partition table kjournald starting. Commit interval 5 seconds EXT3 FS on md9, internal journal EXT3-fs: mounted filesystem with writeback data mode. md: md13 stopped. md: bind<sda4> raid1: raid set md13 active with 1 out of 1 mirrors md13: bitmap initialized from disk: read 4/4 pages, set 0 bits created bitmap (57 pages) for device md13 md13: unknown partition table kjournald starting. Commit interval 5 seconds EXT3 FS on md9, internal journal EXT3-fs: mounted filesystem with writeback data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on md9, internal journal EXT3-fs: mounted filesystem with writeback data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on md13, internal journal EXT3-fs: recovery complete. EXT3-fs: mounted filesystem with writeback data mode. sd 8:0:0:0: [sdi] Assuming drive cache: write through sdi: sdi1 usbcore: registered new interface driver hiddev usbcore: registered new interface driver usbhid usbhid: v2.6:USB HID core driver usbcore: registered new interface driver usblp sysinfo: Module loaded. ufsd: module license 'Commercial product' taints kernel. Disabling lock debugging due to kernel taint ufsd: driver 8.1 (018_A) LBD=ON with ioctl loaded at bf0a2000 NTFS read/write support included Hfs+/HfsX read/write support included eth0: link up, 100 Mb/s, full duplex, flow control disabled kjournald starting. Commit interval 5 seconds EXT3 FS on md9, internal journal EXT3-fs: mounted filesystem with writeback data mode. md: bind<sda2> md: md1: raid array is not clean -- starting background reconstruction raid1: raid set md1 active with 1 out of 1 mirrors md1: unknown partition table Adding 530040k swap on /dev/md1. Priority:-1 extents:1 across:530040k Clear RTC Alarm interrupt. Clear RTC Alarm interrupt. active port 0 :139 active port 1 :445 active port 2 :20 kjournald starting. Commit interval 5 seconds EXT3 FS on sda3, internal journal EXT3-fs: mounted filesystem with ordered data mode. eth0: link up, 100 Mb/s, full duplex, flow control disabled active port 0 :139 active port 1 :445 active port 2 :20 warning: `proftpd' uses 32-bit capabilities (legacy support in use) NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory NFSD: starting 90-second grace period iSCSI Enterprise Target Software - version 1.4.18 iscsi_trgt: Registered io type fileio iscsi_trgt: Registered io type blockio iscsi_trgt: Registered io type nullio warning: process `pic_raw' used the deprecated sysctl system call with 8.1.2. Set Adpater:port=0:0 standby to 241 (1800 secs). active port 0 :139 active port 1 :445 active port 2 :20 rule type=2, num=0 Loading iSCSI transport class v2.0-871. iscsi: registered transport (tcp) sd 8:0:0:0: [sdi] Unhandled sense code sd 8:0:0:0: [sdi] Result: hostbyte=0x00 driverbyte=0x08 sd 8:0:0:0: [sdi] Sense Key : 0x3 [current] sd 8:0:0:0: [sdi] ASC=0x11 ASCQ=0x0 end_request: I/O error, dev sdi, sector 1111 sd 8:0:0:0: [sdi] Unhandled sense code sd 8:0:0:0: [sdi] Result: hostbyte=0x00 driverbyte=0x08 sd 8:0:0:0: [sdi] Sense Key : 0x3 [current] sd 8:0:0:0: [sdi] ASC=0x11 ASCQ=0x0 end_request: I/O error, dev sdi, sector 1111 sd 8:0:0:0: [sdi] Unhandled sense code sd 8:0:0:0: [sdi] Result: hostbyte=0x00 driverbyte=0x08 sd 8:0:0:0: [sdi] Sense Key : 0x3 [current] sd 8:0:0:0: [sdi] ASC=0x11 ASCQ=0x0 end_request: I/O error, dev sdi, sector 1111 sd 8:0:0:0: [sdi] Unhandled sense code sd 8:0:0:0: [sdi] Result: hostbyte=0x00 driverbyte=0x08 sd 8:0:0:0: [sdi] Sense Key : 0x3 [current] sd 8:0:0:0: [sdi] ASC=0x11 ASCQ=0x0 end_request: I/O error, dev sdi, sector 1111
Ich hoffe es hilft weiter, eine Lösung zu finden.
Ob es an dem Update der Firmware auf 3.2.7 Build 0526T liegen kann?
Danke schon mal
_ulf
Hi,
Die letzten Zeilen des dmesg-outputs gefallen mir gar nicht. Ich nehme an, sdi ist Deine externe USB-Festplatte. Sense Key : 0x3: ASC=0x11 ASCQ=0x0 bedeutet einen unkorrigierbaren Lesefehler, siehe: http://dlc.sun.com/pdf/817-5918-10/817-5918-10.pdf
Das kann nun verschiedene Ursachen haben:
1) Deine Platte ist defekt.
2) Dein Kabel oder auch USB-Controller verursachen Übertragungsprobleme.
3) Die Fehlermeldung ist falsch weil der USB-Controller nen Fehler hat und nicht richtig funktioniert.
Für 3) gibt es im Linux-Kernel ne riesen Liste von USB-Geräten, wo deren Fehlverhalten hinterlegt ist, d.h. gegebenenfalls "Fehler" ignoriert oder umgangen werden. Da hat man dann mit neu am Markt befindlichen Geräten und nen alten Kernel schlechte Karten. Hier im Forum heißt das dann einfach, die Platte ist nicht kompatibel
Vielleicht versuchst Du es ja mal mit einer anderen Platte. Ansonsten noch mal Kabel prüfen oder gegebenenfalls Platte an eine externe Stromversorgung anschließen.
Bei mir funktioniert die USB-Platte auch nicht zuverlässig, obwohl ich ziemlich viel probiert habe. Sporadisch gibt es Abbrüche wegen Lese- oder Schreibfehler. Ich tippe auf ein "Hardwareproblem", d.h. der USB-Controller steigt irgendwann aus, warum auch immer. Vielleicht wird er zu warm oder die Platine ist schlecht designed und es gibt Übertragungsprobleme mit entsprechend erhöhten Fehlerraten etc. Da es aber selten auftritt, nutze ich die USB-Platte trotzdem für Backups mit rsnapshot (rsync), denn rsync überprüft, ob die Daten fehlerfrei übertragen worden sind und kann nach Abbruch einfach neu aufgerufen werden, um an der Abbruchstelle fortzusetzen.
Linuxnutzer
Zitat von "jekie"Alles anzeigenSalut
Noch eine Info als Hiweis für die Experten: Ich habe gesehen, dass Winscp ja auch einen Befehl zum synchronisieren enthält. Den habe ich mal benutzt.
Da kommt dann nach kurzer Zeit als Fehlermeldung:
Kann Pfad für /share/external/sdy5/Public/Für J+K nicht anlegen
Datei oder Verzeichnis nicht gefunden.
Fehlernummer: 2
Fehlermeldung vom entfernten Rechner : No such file
Anforderungsnummer: 14
(Dabei wird der Umlaut so angezeigt: für J+K)
Kann es sein, dass der sync-Befehl Probleme mit Umlauten im Dateinamen oder in der Pfadangabe jhat und dabei denn abbricht???
Ja, das ist möglich. Ich kenne Winscp nicht, aber es gibt bestimmt eine Option wie "Remote Charset" bzw. "Zeichensatz auf entferntem Rechner", der sollte dann auf UTF-8 gestellt werden.
Linuxnutzer