Schlagwort-Archive: Linux

Software

Now fail already! Wenn der Browser über Umwege XOrg lahmlegt

Schreibe einen Kommentar

Ugh. Schon wieder. Das Rattern in der Ecke hat meist eine recht konstante Ursache: Die CPU meines Laptops läuft auf 100% und sorgt für ordentliche Lüfterdrehzahlen. Gehen wir mal auf Ursachensuche:

Bei CPU-Last ist erster Anlaufpunkt natürlich top/htop. In meinem Fall aber leider nicht sehr Hilfreich: Xorg sei der Verursacher. Weites Feld. Aus meiner Erfahrung geht dann der Blick erst mal auf die laufenden Programme. Nicht selten hat sich auf einer geöffneten Webseite eine Flash-Werbung, ein HTML5-Video oder sonstige zappelnde Dinge mit Nervfaktor versteckt und bringen das Rendering in Gang. Leider konnte ich dieses mal nichts finden. Auch der interne Taskmanager von Google Chrome zeigt – anders als in solchen Fällen üblich – keine auffällig hohen Lasten. Um sicher zu gehen halte ich per SIGSTOP alle UI-Programme kurz an – keine Änderung. Es ist also mit hoher Wahrscheinlichkeit keine Grafikausgabe, welche die Probleme auslöst.

Zurück zum Start. Wir wissen, dass Xorg die Last bringt, allerdings vermutlich nicht im Grafikbereich. Schauen wir uns top nochmal genauer an. Die Browser sind noch in SIGSTOP und entsprechend verschwunden. Hinter XOrg macht sich nun dbus breit. Dbus? Kurze Lastspitzen OK, aber Dauerlast? Ein Blick mit dbus-monitor bringt eine Wall-of-log zum Vorschein:

method call time=1462212788.744495 sender=:1.1259306 -> destination=org.freedesktop.DBus serial=6 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=RemoveMatch
   string "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',path='/org/freedesktop/DBus',arg0='org.gtk.vfs.Daemon'"
method return time=1462212788.744507 sender=org.freedesktop.DBus -> destination=:1.1259306 serial=6 reply_serial=6
method call time=1462212788.744535 sender=:1.1259306 -> destination=org.freedesktop.DBus serial=7 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',path='/org/freedesktop/DBus',arg0='org.gtk.vfs.Daemon'"
method return time=1462212788.744544 sender=org.freedesktop.DBus -> destination=:1.1259306 serial=7 reply_serial=7
method call time=1462212788.744600 sender=:1.1259306 -> destination=org.freedesktop.DBus serial=8 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=StartServiceByName
   string "org.gtk.vfs.Daemon"
   uint32 0
method return time=1462212788.744611 sender=org.freedesktop.DBus -> destination=:1.1259306 serial=8 reply_serial=8
   uint32 2
method call time=1462212788.744748 sender=:1.1259306 -> destination=org.freedesktop.DBus serial=9 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=GetNameOwner
   string "org.gtk.vfs.Daemon"
method return time=1462212788.744761 sender=org.freedesktop.DBus -> destination=:1.1259306 serial=9 reply_serial=9
   string ":1.1258771"
method call time=1462212788.744895 sender=:1.1259306 -> destination=:1.1258771 serial=10 path=/org/gtk/vfs/mounttracker; interface=org.gtk.vfs.MountTracker; member=LookupMount
   struct {
      array of bytes "/NAME@DOMAIN.org" + \0
      array [
         dict entry(
            string "query"
            variant                array of bytes "subject=blabla&body=blabla" + \0
         )
         dict entry(
            string "type"
            variant                array of bytes "mailto" + \0
         )
      ]
   }
error time=1462212788.745079 sender=:1.1258771 -> destination=:1.1259306 error_name=org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code15 reply_serial=10
   string "Der angegebene Ort wird nicht unterstützt"

…und das in Endlosschleife. Uhm, ja. mailto? Das sind üblicherweise Links in Webseiten oder Dokumenten um E-Mails zu versenden. Stimmt, ich hatte vor einigen Stunden auf einer Webseite einen Mail-Link angeklickt. Ohne Reaktion.

Offenbar hat sich die DE an eben diesem Maillink festgefressen. „Der angegebene Ort wird nicht unterstützt“. Kein Wunder, denn in den „Standardprogrammen“ ist für E-Mails nichts hinterlegt. Anstatt das Ganze aber einfach als Fehlschlag einzuordnen und abzubrechen wird die Aktion in Endlossschleife ständig wiederholt. Da auch Xorg an Dbus hängt (und offenbar nicht sonderlich effizient auf dessen Events reagiert) geht auch dieser in die Knie. Da ich auf die Schnelle keine Möglichkeit fand das dbus-event rauszuwerfen musste ein Dummy-Mailprogramm hinhalten. Event geht rein, Returncode kommt, Dbus gibt Ruhe. Warum nicht gleich so?

BitBastelei

BitBastelei #193 – Backups unter Linux » Borg Backup

2 Kommentare
BitBastelei #193 - Backups unter Linux » Borg Backup

(48 MB) 00:36:23

2016-04-17 10:00 🛈

Existiert kein Backup, sind die Daten nicht wichtig

Diese Aussage ist schön provozierend, treibt gerne Leute in meiner Umgebung zur Weißglut, hat aber einen wichtigen Kern: Wer seine Daten benötigt sollte Datensicherungen haben. Während ich bei den lokalen Servern eine gut funktionierende und getestete Infrastruktur habe liegen mir externe Dienste etwas im Magen. Auf allen Systemen habe ich direkten Zugriff, die Daten sollen übers Netz auf ein Zielsystem gesichert werden. Die Übertragung muss verschlüsselt erfolgen, als zusätzliche Hürde ist die Bandbreite recht gering: Je nach Last kann diese schon mal auf wenige MBit/s sinken oder gar ganz abbrechen. Weiterhin benötige ich schnellen Zugriff auf einzelne Dateien der Sicherung und die Möglichkeit auch ältere Revisionen einer Datei zu erhalten. Hier setzte ich lange Zeit auf rdiff-backup.

Videoinhalt

  • 01:06 Meine Anforderungen
  • 02:51 rdiff-backup // Wie lief mein Backup bisher?
  • 05:10 OwnCloud/BTSync/Sparkleshare
  • 06:33 Unison
  • 07:36 Obnam
  • 10:18 BORG › Was ist BORG?
  • 12:42 BORG › Geschichte
  • 13:39 BORG › Aufbau & Code
  • 14:32 BORG › Sicherheit
  • 15:47 BORG › Kompression
  • 17:39 BORG › Deduplizierung
  • 19:45 BORG › DEMO
  • 33:28 BORG › EOT

rdiff-backup

Das Programm arbeitet über eine SSH-Verbindung und kann nahezu alle unter Linux auftretenden Dateitypen verarbeiten. Auch ACL & Co. ist üblicherweise kein Problem. Wie der Name schon andeutet werden bei bestehenden Dateien nur Änderungen übertragen. Auf dem Zielsystem findet sich nach dem Backup der letzte Stand direkt zugreifbar im Dateisystem – perfekt wenn man nur eine gelöschte Datei schnell zurückspielen muss. Ältere Versionen (bzw. die Differenzen) werden in einem zusätzlichen Ordner gespeichert, über die Software lassen sich ältere Versionen der Dateien dann rekonstruieren.

Eigentlich war ich recht zufrieden mit diesem System. Backupfehler traten nur selten auf, der Restore war einfach und der Ressourcenverbrauch überschauber. Nicht ganz so prickelnd: Die Software, welche auf Python 2 (ja, nicht 3) basiert, hat seit 2009 kein Update mehr gesehen. Zum einen ein Problem wegen der nur schwer noch zu installierenden Python-Version, zum Andern gibt es Gerüchte über mögliche Datenverluste. Auch bei mir hat es zuletzt durch Netzabbrüche das Repository zerlegt, sodass ich mich auf die Suche nach Alternativen machte.

Owncloud, Sparkleshare, BTSync & Co

…sind auf Desktop-Systemen schöne Systeme, für Datensicherungen aber eher wenig geeignet. Zwar gibt es die Möglichkeit auf ältere Versionen zugreifen zu können, die Archivverwaltung ist aber meist nicht sehr flexibel. Auch die Unterstützung erweiterter Attribute ist prinzipbedingt meist nicht gegeben. Größtes Problem für mein Vorhaben: Mit großen Datenmengen kommen solche Programme nicht wirklich klar.

Unison

Unison fällt in etwa in die selbe Kategorie, schien aber besser optimiert. Leider zeigt sich die Revisionsverwaltung für meine Zwecke etwas unflexibel. Auch die genutzte Programmiersprache OCaml ist nicht unbedingt etwas, was für mich leicht anpassbar aussieht. Zuletzt ist auch hier die Unterstützung von Metadaten unter Linux noch ausbaufähig.

Obnam

…wird bei vielen als „Drop-In-Replacement“ beworben. Die Funktionen ähneln rdiff-backup, jedoch wird zusätzlich eine Deduplizierung und Verschlüsselung unterstützt. Die Software muss nur auf einem System installiert werden, am Ziel werden „Chunks“ abgelegt, ein direkter Zugriff auf Dateien ist entsprechend nicht mehr möglich.

Bei mir wollte die Software nicht sonderlich mitspielen – Backups dauerten ewig, Verbindungsabbrüche führten zu verwaisten Locks und Mangels brauchbarem Verbose-Mode ist nur schwer zu ermitteln was genau die Software aktuell überhaupt versucht zo erledigen.

(Wir sind die) Borg

Der Funktionsumfang von BorgBackup ist Ähnlich zu Obnam: Deduplizierung, Kompression, Verschlüsselung und Co. Der Fork der Software Attic hat vor kurzem die Version 1.0.0 erreicht. Hier ist der direkte Zugriff nicht über ein FUSE-Modul möglich. Mit Ausnahme von dateisystemspezifischen Attributen werden ACLs und Xattr samt den meisten Device-Files und FIFOs mitgesichert.

Erster Eindruck: Scheint recht sauber zu laufen, das Projekt sieht gut dokumentiert aus. Die Optionen erlauben es alle Dateien und laufenden Abläufe auf der Konsole anzuzeigen – gerade bei meiner Konstellation sehr praktisch, da ich so direkt sehe ob überhaupt noch etwas passiert. Obendrein kann man auch gleich die Effizienz von Kompression und Deduplizierung schon während des Backups sehen. Die fehlende Konfigurationsdatei lässt sich über passende Shellscripte kompensieren, führt auf meinem 1080p-Monitor allerdings auch zu einem 4-zeiligen Progammaufruf. Der 200GB-Datensatz eines meiner Server mit 10 Revisionen passt auf etwa 75GB. Minuspunkte gibt es für die Tatsache, dass das Grundsystem (mit Ausnahme von Kompression/Deduplizierung) nicht mit mehreren Threads klar kommt. Gerade bei großen Repositories führt das doch zu der ein oder anderen Wartezeit.

Momentan sieht BORG als vielversprechendste Lösung aus, bietet es doch den größten Funktionsumfang, eine aktive Weiterentwicklung und bisher keine nennenswerten Programmfehler. Sicher nicht so ausgearbeitet wie große Lösungen wie Amanda oder Bacula, für die meisten Anwendungen aber ausreichend und wesentlich einfacher einzurichten.

PC-Kram

[nvidia/qt5/kdenlive] Segfault on various KDE-software using NVIDIA 361.16

Schreibe einen Kommentar

Uhm crap. The last system update just pulled a new beta version of NVIDIAs binary driver. Usually not that much of a deal, I went for testing due to a bug in their stable driver some years ago and never ran into a problem. Well, at least until now.  This time the testing-curse found its way into my system and I found myself no longer able to start my video editor kdenlive. Segmentation Fault. I suspected my setup first since I am running a rather unusual multihead configuration but could also with just one monitor I ran into the same problem. Well, looks like I have to dig deeper. Some gdb later at least a clue:

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff0b640c5 in XScreenCount (dpy=0x0) at Macros.c:109
109	int XScreenCount(Display *dpy) { return (ScreenCount(dpy)); }
(gdb) bt
#0  0x00007ffff0b640c5 in XScreenCount (dpy=0x0) at Macros.c:109
#1  0x00007fffea7f50da in glXGetClientString () from /usr/lib/libGLX.so.0
#2  0x00007ffff7fed3b3 in ?? () from /usr/lib/qt/plugins/xcbglintegrations/libqxcb-glx-integration.so
#3  0x00007ffff7fed5b1 in ?? () from /usr/lib/qt/plugins/xcbglintegrations/libqxcb-glx-integration.so
#4  0x00007ffff686fc7b in QSGRenderLoop::instance() () from /usr/lib/libQt5Quick.so.5
#5  0x00007ffff68a19e5 in QQuickWindowPrivate::init(QQuickWindow*, QQuickRenderControl*) () from /usr/lib/libQt5Quick.so.5
#6  0x00007ffff694b68d in QQuickView::QQuickView(QWindow*) () from /usr/lib/libQt5Quick.so.5
#7  0x00000000006bd190 in ?? ()
#8  0x00000000006c3d7b in ?? ()
#9  0x00000000007af3cc in ?? ()
#10 0x000000000046346b in ?? ()
#11 0x00007ffff188e610 in __libc_start_main () from /usr/lib/libc.so.6
#12 0x0000000000463949 in _start ()

So XScreenCount or libGLX is the suspect. In my case GLX is provided by NVIDIAs binary driver (nouveau had limited multihead support last time I checked). Also some QT5-stuff is mentioned in the backtrace.

A bit of search engine voodoo later it turns out NVIDIA already acknowledged the problem. Aaron Plattner writes:

I reproduced the problem and tracked it down to this buggy code in Qt5’s qxcbglxintegration.cpp:

static bool vendorChecked = false;
    static bool glxPbufferUsable = true;
    if (!vendorChecked) {
        vendorChecked = true;
        const char *glxvendor = glXGetClientString(glXGetCurrentDisplay(), GLX_VENDOR);
        if (glxvendor && !strcmp(glxvendor, "ATI"))
            glxPbufferUsable = false;
    }

When this code is called during sddm-greeter startup, there’s no current GLX context, so this gets called with a NULL argument.

While here SDDM is not the problem I think kdenlive, which uses similar libraries, runs into the same problem. He also pushed a corresponding patch to NVIDIAs GIT-repository. Sadly the current HEAD is not 100% ABI compatible with the official driver release. Also I really didn’t want to get into my distributions xorg-packaging-foo. Ultimately I reverted to the current NVIDIA stable version 358.16 to get back into business. So – lesson confirmed: Beta releases can fix problems or cause problems. But who doesn’t like a bit of stability-gambling, right?

BitBastelei

BitBastelei #171 – ZFS on Linux

2 Kommentare
BitBastelei #171 - ZFS on Linux

(41 MB) 00:23:38

2015-10-25 11:00 🛈

ZFS ist ein Speichersystem, welches den Aufbau professioneller Speichersysteme ermöglicht.

02:55 – Inodes
03:43 – Blockgrößen
04:31 – Copy on Write
06:25 – Snapshots
07:25 Transaktionssicherheit bei Backups
18:10 – BTRFS https://www.youtube.com/watch?v=y-yYc4sP9zM

Software

SSH Root-Login auf Debian Jessie aktivieren

Schreibe einen Kommentar

„Mal schnell“ einen Server mit Debian aufsetzen – kann ja nicht so schwer sein. Dachte ich. Eine Kleinigkeit ist jedoch zu beachten: Mit der tasksel-Auswahl „SSH-Server“ wird dieser zwar installiert und passend gestartet, standardmäßig ist der Login jedoch nur mit dem zusätzlich erstellten User möglich, nicht jedoch als root.

Da ich für den Server Remote-Scripte laufen habe, welche bisher nicht auf ein User->sudo-System ausgelegt sind, ist für mich ein SSH root-Login unumgänglich. Um diesen auf dem Debian-System zu aktivieren öffnet man die Datei /etc/ssh/sshd_config und entfernt bzw. kommentiert (# davor) die folgende Zeile:

PermitRootLogin without-password
Software

Notizzettel: Wenn mal wieder sinnlose Fehler auftreten…

Schreibe einen Kommentar

Wenn man plötzlich mit recht nichtssagenden Meldungen wie 

Version: 2.1.1, Linux Version: 2.1.1, Package Iteration: 
go get -v github.com/tools/godep
github.com/tools/godep
go build github.com/tools/godep: /usr/lib/go/pkg/tool/linux_amd64/link: signal: killed
exit status 1
exit status 1

oder auch

remote: Counting objects: 56476, done.
remote: Compressing objects: 100% (12/12), done.
remote: Total 56476 (delta 0), reused 0 (delta 0), pack-reused 56464
Receiving objects: 100% (56476/56476), 94.21 MiB | 6.98 MiB/s, done.
error: index-pack died of signal 92)   
fatal: index-pack failed

beworfen wird, so kann die Ursache auch recht banal und im Log schnell auffindbar sein:

Out of memory: Kill process 2308 (git)

Eyeup, die Kiste hat recht wenig RAM und keinen SWAP eingerichtet – könnte krachen, vor allem wenn Speicherfresser wie node.js mitreden möchten. Auch kann es in diesem Fall helfen /tmp nicht als Ramdisk (tmpfs) laufen zu lassen.

Software

ZFS: Dateien trotz vollem Datenträger löschen

Schreibe einen Kommentar

Narf – da war der Bug schneller als der Admin hinter dem Monitoring: 0k freier Speicher vermeldet ein ZFS-Storage. Na kein Problem, kaputtes Programm gestoppt und schnell mal den Schrott gelöscht. Oder auch nicht:

rm: cannot remove file: Disk quota exceeded

Really?!

Ursache wäre wohl „COW“ – Copy on write. Bei Änderungen werden die neuen Daten erst mal auf die Festplatte geschrieben – erst wenn dort kein Fehler auftritt werden die entsprechenden Zeiger im Dateisystem aktualisiert und die vorherigen Daten ungültig.

Die Lösung, welche z.B. bei der Uni Freiburg zu finden ist, ist effektiv, aber mir nicht wirklich verständlich: Anstatt die Datei zu löschen wird sie erst mit /dev/null überschrieben – dies schlägt trotz COW offenbar nicht fehl. Der so freigewordene Speicherplatz, welche zuvor durch den Inhalt der Datei belegt wurde, sollte nun ausreichen um den Löschbefehl umzusetzen:

rm test
#rm: cannot remove file `test': Disk quota exceeded
cp /dev/null test
rm test
stat test
stat: der Aufruf von stat fuer "test" ist nicht moeglich: Datei oder Verzeichnis nicht gefunden
Software

Squid als Proxy-Server

Schreibe einen Kommentar

„Mein Internet ist kaputt“ – ich denke jeder 1st-Leveler kennt diese Aussagen. Bauchschmerzen bereiten sie spätestens dann, wenn auch man selbst nicht mehr ins Netz kommt. Proxy weg. In solchen Situationen muss schnelle Hilfe her. Mein erster Blick: Da steht noch ne Testkiste – zwar ist Arch Linux nicht unbedingt die erste Wahl für Produktivserver, welche möglichst wartungsarm sein sollen, aber besser als nichts. Bauen wir mal einen Proxy.

1. Squid installieren

Die Platzhirsch unter den Proxys dürfte ohne Frage Squid sein. Die GPL-Software kann sowohl als Caching als auch Reverse Proxy eingesetzt werden. Ich nutze nur die erste Funktion – Zugriffe der Benutzer sollen zwischengespeichert werden. Die Installation ist unter nahezu allen Distributionen mit wenigen Schritten über den Paketmanager möglich. In meinem Fall reicht ein „pacman -S squid“.

2. Zugriffs- und Speicherkonfiguration

Neben der Software wird auch eine Standardkonfiguration installiert, welche unter /etc/squid/squid.conf zu finden ist. Standardmäßig wird den privaten IPv4-Bereichen erlaubt auf die üblichen Ports für HTTP, FTP, Gopher, Wais und HTTPs zu verbinden. Sofern man keine restriktive Webzugriffslinie besitzt können diese Beispiele also übernommen werden. Einige Änderungen und Ergänzungen können allerdings Hilfreich sein:

# Keine Verbindung zu localhost - schuetzt ggf. falsch eingerichtete Webanwendungen auf dem Server
http_access deny to_localhost

#E-Mail-Adresse des Admins - so kommen die Beschwerden der Nutzer an die richtige Stelle
cache_mgr info@ad....fo

#Beim Stoppen des Dienstes 10 Sekunden darauf warten laufende Uebertragungen abzuschliessen
shutdown_lifetime 10 seconds

#Im RAM werden bis zu 4 GB als Cache genutzt
cache_mem 4096 MB

#Objekte mit mehr als 50MB werden nicht gecached
maximum_object_size 50 MB

# Bis 95% Fuellstand des Caches werden keine Objekte ersetzt
cache_swap_low 95

# Je naeher wir an 98% kommen desto aggressiver werden alte Objekte ersetzt
cache_swap_high 98

#Alles ueber 512kb wird nicht im RAM sondern nur auf HDD gespeichert
maximum_object_size_in_memory 512 KB

# HDD-Cache Typ aufs (async), Ordnerangabe, 32GB, Ordner erste Ebene, Ordner zweite Ebene
cache_dir aufs /var/cache/squid 32768 32 256

#Eyecandy
visible_hostname proxy.lan.adlerweb.info

#Boese Seiten
acl bad_url dstdomain "/etc/squid/bad-sites.acl"
http_access deny bad_url

#Interne IP des Clients nicht nach draussen senden
forwarded_for off

In meinem Fall musste auch der Standardport dran glauben, stattdessen wird nun 8080 verwendet, welches dem Altsystem entspricht und lästiges Umkonfigurieren erspart:

http_port 8080

3. Diktator-Modus

In der Konfiguration schimmert es schon etwas durch: I aim to misbehave. Da es sich um mein Netz handelt greifen auch meine Zensurrichtlinien. Unter /etc/squid/bad-sites.acl liegt eine Liste mit Domains, welche vom Proxy gesperrt werden. Dies kann z.B. sinnvoll sein um Werbung oder die Ziele quasselfreudiger Programme auszusperren. Dabei solltet ihr natürlich das alte Credo beherzigen: With great power comes great responsibility.

.facebook.com
.facebook.de
.google-analytics.com
.googleadservices.com
[...]

4 Minuten Später
…ist der Proxy installiert und das Internet läuft wieder. Job erledigt, wenden wir uns wieder den Katzenvideos zu.

Und sonst?
Wer es etwas weiter treiben möchte: SquidGuard oder Dansguardian können Webseiten nach Themenbereichen sperren. SquidClamav kann die aufgerufenen Webseiten auf Viren prüfen. Sarg verwandelt das Log in einen praktischen HTML-Report mit Top-Usern und den Beliebtesten Webseiten. Ansonsten hat auch sicher die Suchmaschine der Wahl noch genügend Ideen zur Freizeitvernichtung.

Software

Linux: Partitionen innerhalb einer Image-Datei/LV mounten

2 Kommentare

Bisher speicherte ein Windows-System seine Datensicherung per CIFS (aka Samba) auf einer Linux-basierten NAS. Das Konzept ist dabei schon etwas älter – die Windows-Software unterstützte bei der Einrichtung weder Kompression noch Deduplizierung, sodass hier das ZFS-Dateisystem der Linux-Kiste einiges an Platz einsparen konnte. Inzwischen ist die Windows-Software gewachsen: Kompression und Deduplizierung werden bereits vorab durchgeführt, dafür machten die vielen neuen Funktionen immer häufiger Probleme mit CIFS. Kaputte Locks, schlechte Performance, Verbindungsabbrüche – alles lässt sich recht genau auf die Kombination aus dem Server und CIFS zurückführen. Während eine „normale“ Kopie unter Linux mit etwa 100MB/s von statten geht schafft der Server nur 4MB/s. Andere Protokolle sind schneller, andere Windows-Server haben ebenfalls keine Probleme. Inzwischen sind ohnehin neue Platten fällig – Zeit hier gegenzusteuern.

Die Speicherung soll weiterhin auf der Linux-Kiste erfolgen – dort ist die Sicherung und Verwaltung deutlich zuverlässiger und flexibler. Andererseits habe ich keine Lust auf CIFS-Fehlersuche, also lassen wir es einfach weg – die Lösung: iSCSI. Der Windows-Server greift direkt auf den rohen Datenträger des Linux-Systems zu. Da wie erwähnt keine Linux-seitige Kompression stattfinden muss wird diese einfach per LVM verwaltet und ist über den Kernel-iSCSI-Server exportiert. Das Anlegen verläuft ohne Probleme, müssen nur noch die Daten rüben. Mit 4MB/s. Bei fast 4TB. Mit 5 Tagen Restzeit. Nope.

Also, fassen wir nochmal zusammen: Sowohl der alte als auch der neue Datenbestand liegen auf dem selben Linux-System. Warum nicht einfach da kopieren? NTFS-Schreiben unter Linux ist zwar nicht schnell, aber die 4MB/s-Marke sollte zu schaffen sein. Problem: Auf dem LVM-LV hat Windows automatisch eine GPT-Partitionstabelle angelegt, sie lässt sich also nicht direkt unter Linux mounten.

Um trotzdem an das NTFS-System zu kommen müssen wir erst mal wissen wo die passende Partiton beginnt. Hier kommt parted zum Einsatz, welcher auch GPT-Partitionstabellen unterstützt. Da wir die Angaben in Byte, nicht den üblichen Sektoren, benötigen muss die Anzeige erst ungeschaltet werden.

[root@nas ~]# parted /dev/speicher2/windows9
GNU Parted 3.2
/dev/dm-1 wird verwendet
Willkommen zu GNU Parted! Rufen Sie "help" auf, um eine Liste der verfügbaren Befehle zu erhalten.
(parted) unit B
(parted) print
Modell: Linux device-mapper (linear) (dm)
Festplatte  /dev/dm-1:  4178147540992B
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: gpt
Disk-Flags:

Nummer  Anfang      Ende            Größe           Dateisystem  Name                          Flags
 1      17408B      134235135B      134217728B                   Microsoft reserved partition  msftres
 2      135266304B  4178146492415B  4178011226112B  ntfs         Basic data partition          msftdata
(parted) quit

Wie wir sehen wurden auf dem LVM-LV durch Windows zwei Partitionen angelegt: Die Erste enthält Managementdaten, die Zweite ist unsere eigentliche NTFS-Datenpartition. Letztere beginnt bei 135266304 Byte – genau diesen Bereich müssen wir auf dem Datenträger also überspringen um auf das NTFS-Dateisystem zugreifen zu können. Also legen wir uns ein passendes Loop-Device an. Da ich bereits ein anderes Device aktiv habe nutze ich loop2 – generell ist die Zahl wählbar.

[root@nas ~]# losetup -o 135266304 /dev/loop2 /dev/speicher2/windows9
[root@nas ~]# mount -t ntfs-3g /dev/loop2 /mnt/test/
[root@nas ~]# mount | grep test
/dev/loop2 on /mnt/test type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other,blksize=4096)
[root@nas ~]# df -h test/
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/loop2      3,8T    604G  3,3T   16% /mnt/test

Passt doch, schon haben wir unter Linux nativen Zugriff auf das Device. Das Kopieren läuft nun mit 90MB/s – nicht ganz die bestmögliche Geschwindigkeit, für NTFS über fuse aber kein Schlechter wert – und etwas schneller als die 4MB/s der Windows-Kiste.

Software

BTRFS-Recovery

Schreibe einen Kommentar

Narf… Das war zu viel. Durch einen Umbau hatte sich offenbar ein Kabel im Lüfter meines Chipsatzes verheddert – keine gute Voraussetzung, wenn man mal eben Wine neu kompiliert. Es kommt, was kommen musste: Kernel panic.

Nunja, Fehler gefunden, weiter gehts. Nicht. Zwar startete das System, meine Home-Partition blieb aber verschwunden. Kurzer Blick auf den Aufbau: Mein Home liegt auf einer separaten Partition, ist mit LUKS verschlüsselt und nutzt – da ich die gigabyteweise IRC-Logs vorratsdatenspeichere und transparente Komprimierung wollte – BTRFS. Das Log verrät: LUKS selbst läuft, mount hingegen scheint sich aufzuhängen. In dmesg sieht alles OK aus, nur die normalen BTRFS-Meldungen, keine Fehler.

Strange, aber Reboot fixed ja fast alles, also schnell die magischen Zeichen eingetippt und zur Sicherheit im Rescue-Mode gestartet. Dort per Hand cryptsetup aufgerufen und erst mal btrfsck losgelassen. Kein Fehler. Mount? Nope.

OK, nun bin ich genervt, vor allem da die Kiste nicht unbedingt schnell bootet. Qemu to the rescue, also schnell ein Debian geklont und die Partition vorgesetzt. Schlechte Idee. Die bei Debian genutzten BTRFS-Libs/Module sind eine Nummer zu alt und können mit der Partition gar nichts anfangen. Ein Arch-Download später kann es weiter gehen.

Erst einmal ein normaler mount in der VM – vielleicht ist ja nur der Host kaputt, außerdem ist auf der CD ein älterer Kernel. Leider ohne erfolg, also VM-Reboot und den Hammer ausgepackt. Mit „mount -o recovery,nospace_cache“ lassen sich viele Fehler schon beheben, aber auch hier scheint der mount nichts zu vollziehen. Keine Reaktion, keine IO-Last, keine Fehlermeldung.

Die Lösung: btrfs_zero_log. Hiermit werden die offenen Transaktionen gelöscht. Die kann zwar zu Datenverlust von Änderungen, die kurz vor Absturz geschrieben wurden, führen, aber besser als gar keine Partition. Der mount in der VM war schlussendlich erfolgreich und auch der Host verfügte kurze Zeit später wieder über alle Dateien. Warum btrfsck das offenbar defekte Log nicht ankreidete ist mir allerdings ein Rätsel – sollte das nicht die Aufgabe des Tools sein?