Rätselhafter Crash bei großen Datentransfers via Pipe

[daemotron]

Hallo,

ich schaffe es reproduzierbar, meinen Server zum Absturz zu bringen, indem ich eine größere Datenmenge per tar in ein Archiv packe und per Pipe an ncftpput übergebe:

Code: Select all

cd /verzeichnis/mit/daten
tar -cjpf - * | ncftpput -c -V -u xxxxx -p ***** xx.xx.xx.xx /backup/sys/stage-svr.www.ex3-20070329.tar.bz2

In dem Fall war es eine komplette Linux-Installation in einem chroot - hab einen Snapshot vom LVM2-Volume angefertigt, gemountet (ro) und dann obigen Befehl ausgeführt.

Allerdings crasht die Kiste auch, wenn ich so ein Konstrukt auf Daten loslasse, die auf einer normalen Partition (egal ob primär oder erweitert) liegen - wenn ca. 200MB über die Pipe gegangen sind, ist Ende Gelände:

Code: Select all

tar: usr/portage/app-dicts/myspell-uk/myspell-uk-20060316.ebuild: Read error at byte 0, while reading 618 bytes: Input/output error

für jede weitere noch zu packende Datei, außerdem

Code: Select all

tar: Error exit delayed from previous errors
Bus error

Beim Versuch, noch irgendwelche Kommandos abzusetzen (auch auf anderen noch offenen SSH-Verbindungen) lautet die Antwort immer ähnlich

Code: Select all

~# lvs
Bus error
~# netstat -tulpen
-su: netstat: command not found
~# reboot
-su: /sbin/reboot: Input/output error

Nach einem Reboot (erzwungen) ist alles wieder völlig normal, und in den Logs findet sich keine Spur - einfach rein gar nichts, was darauf hindeuten könnte, was da schiefgeht. Nur dass die Dateisysteme beim booten geflickt werden, verrät dmesg:

Code: Select all

3ware Storage Controller device driver for Linux v1.26.02.002.
scsi0 : 3ware Storage Controller
3w-xxxx: scsi0: Found a 3ware Storage Controller at 0xe000, IRQ: 18.
scsi 0:0:0:0: Direct-Access     3ware    Logical Disk 0   1.2  PQ: 0 ANSI: 0
SCSI device sda: 625140400 512-byte hdwr sectors (320072 MB)
sda: Write Protect is off
sda: Mode Sense: 00 00 00 00
SCSI device sda: write cache: enabled, read cache: disabled, supports DPO and FUA
SCSI device sda: 625140400 512-byte hdwr sectors (320072 MB)
sda: Write Protect is off
sda: Mode Sense: 00 00 00 00
SCSI device sda: write cache: enabled, read cache: disabled, supports DPO and FUA
 sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 sda8 sda9 >
sd 0:0:0:0: Attached scsi disk sda
sd 0:0:0:0: Attached scsi generic sg0 type 0
serio: i8042 KBD port at 0x60,0x64 irq 1
mice: PS/2 mouse device common for all mice
device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: dm-devel@redhat.com
ip_tables: (C) 2000-2006 Netfilter Core Team
input: AT Translated Set 2 keyboard as /class/input/input0
arp_tables: (C) 2002 David S. Miller
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Starting balanced_irq
Using IPI Shortcut mode
EXT3-fs: INFO: recovery required on readonly filesystem.
EXT3-fs: write access will be enabled during recovery.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: sda3: orphan cleanup on readonly fs
ext3_orphan_cleanup: deleting unreferenced inode 78398
EXT3-fs: sda3: 1 orphan inode deleted
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with journal data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 172k freed
EXT3 FS on sda3, internal journal
kjournald starting.  Commit interval 5 seconds
EXT3 FS on sda5, internal journal
EXT3-fs: mounted filesystem with journal data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on sda6, internal journal
EXT3-fs: mounted filesystem with journal data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on sda7, internal journal
EXT3-fs: mounted filesystem with journal data mode.
Adding 4000760k swap on /dev/sda2.  Priority:-1 extents:1 across:4000760k

Was funktioniert:

• Ich kann die Daten per tar packen und erst mal lokal speichern und dann per ncftpput hochladen
• Ich kann das Pipe-Konstrukt im Rettungssystem einsetzen - nur nicht auf meinem System

Das ganze ist mühelos reproduzierbar - erst dachte ich, es sei mein Kernel. Aber sowohl mit dem 2.6.18, 2.6.19 als auch jetzt mit dem 2.6.20 (jeweils gebaut aus den Gentoo hardened-sources) krieg ich den Abschuss hin. Ach ja, bei den Dateisystemen sind auch keine Exoten dabei - ext2 und ext3 für die meisten Partitionen, für die LVMs XFS.

[Joe User]

Keine Lösung, nur ein Verbesserungsvorschlag:

Code: Select all

tar -cjSp --atime-preserve --numeric-owner -f - . | ncftpput ...

Kannst Du den Error auch auf nicht-LVM Partitionen reproduzieren?

[daemotron]

Ja, sonst hätte ich auch auf LVM als Verursacher getippt... schlimmer noch: selbst wenn kein LVM gemounted ist, geht's schief (hab allerdings LVM fest im Kernel drin, sonst hätte ich mal ohne LVM-Modul getestet).

Wie gesagt, mit kleineren Datenmengen funktioniert's - erst wenn das Archiv eine Größe von ~200MB erreicht wird's kritisch.

Hab gerade mal mit Deiner Konstruktion (danke für die Tipps) einen LVM-Snapshot gepackt - allerdings auf die Pipe verzichtet und die tar-Datei auf einem zweiten LVM-Volume abgelegt. Wenn LVM die Last nicht abkönnte, hätte er eigentlich wieder zusammenbrechen müssen... lief aber durch :?:

EDIT Hinweise, dass es was mit der Pipe zu tun haben könnte, verdichten sich - bin beim surfen auf diesen Thread gestoßen - vermute mal, dass mein Pipe-Buffer volläuft, weil tar schneller Daten reinpumpt als ncftp Daten rausholt und zum Backup-Server schieben kann... werde mal mit verschiedenen Einstellungen experimentieren...

[daemotron]

OK, ich glaube, ich kann den Fehler jetzt nachvollziehen. Offenbar verliert ncftp bei großen Transfers hin und wieder die Verbindung zum remoten FTP-Server. Defaultmäßig versucht ncftp aber keinen Reconnect, so dass der Pipe-Cache tatsächlich irgendwann einfach überläuft, weil keine Daten mehr daraus abfließen können.

Lösung:

Code: Select all

tar -cjSp --atime-preserve --numeric-owner -f - . | ncftpput -c -z -V -u xxxxx -p ***** xx.xx.xx.xx /backup/archiv.tar.bz2

[daemotron]

OK, ich glaube jetzt die Ursache eingegrenzt und eine Lösung gefunden zu haben. Die schwache FTP-Verbindung führt dazu, dass der Pufferspeicher für stdin (bei einem aktuellen Kernel 33 Pages à 4KB = 132KB) volläuft.

Lösung: Die Anzahl Speicherseiten für stdin erhöhen. Das geht allerdings leider nicht in der Kernel-Konfiguration, sondern muss in den Sourcen selbst geändert werden. In der Datei include/linux/binfmts.h die Zeile

Code: Select all

#define MAX_ARG_PAGES 33

ersetzen durch

Code: Select all

#define MAX_ARG_PAGES 256

Danach den Kernel ganz normal mit make übersetzen... danach braucht man sich btw. auch um die beliebten "Argument list too long"-Fehler nicht mehr sorgen - 1MB Argumente muss man erst mal zusammenkriegen

Die Sache hat jedoch auch einen Haken: Für jede Shell, die gestartet wird, wird der entsprechende Speicher vorgehalten. OK, auf meinem System mit 2GB RAM und vielleicht maximal 50 parallelen Shell-Prozessen kein Problem - bei einer Maschine mit weniger RAM und vielen interaktiven Usern (oder Diensten, die viele Shell-Prozesse starten - z. B. Postfix) sei daher unbedingt zur Vorsicht geraten!