Marc Richter's Weblog

Artikel-Schlagworte: „suse“

Ich hatte heute den Fall auf der Arbeit, das ich auf eine an einem unserer Suse Linux Server angeschlossene USB 2.0 Festplatte mehrere Gibibyte an Daten kopieren musste.

Das dauerte …. und dauerte …. schliesslich fiel mir auf, das die Daten mit nur 160 KB/s kopiert wurden. Das kam mir komisch vor, schliesslich sollten die Datenraten von USB 2.0 doch deutlich höher liegen. In diesem Wiki-Artikel fand ich schliesslich heraus, das es (laut Spezifikation) 480 Mbit/s hätten sein sollen; also ca. 60 MebiByte pro Sekunde.
Das hat mich dann schon sehr gewundert, schliesslich ist das nur ca. 1/384tel Bruchteil der Transferkapazität des Buses.

Eine erste Recherche heute auf der Arbeit förderte diesen Foreneintrag von Dezember 2007 zu Tage, in dem der Hinweis gegeben wird, das dieses Problem verschwindet, wenn die mount-Option “sync” weggelassen wird. Als ich es ebenfalls probiert habe ohne “sync” zu mounten, war es auch schlagartig schneller.

Inzwischen habe ich etwas genauer nachrecherchiert:
Bei dem ganzen handelt es sich um einen zumindest bei Novell (Suse) bekannten Bug (siehe Novell Bugzilla Database #105871). Ob er nun nur bei Suse Linux auftritt oder ob es ein genereller Linux Bug ist, das weiss ich nicht. Und ehrlich gesagt bin ich jetzt auch zu faul den ganzen Bug zu lesen. Wer mag, kann das gerne nachholen.

Unter’m Strich bleibt zumindest für Suse Linux in der Version 10.x folgende Lösung: USB Laufwerke nicht mit der mountoption “sync” mounten!
(Ob andere Suse Linux Versionen oder gar andere Distributionen betroffen sind weiss ich nicht; einfach ausprobieren!).

Für per “subfs” gemountete Dateisysteme gibt es einen weiterführenden Workarround um sicher zu stellen, das diese Dateisysteme nicht mit “sync” gemounted werden:

1. mkdir -p /usr/share/hal/fdi/policy/95userpolicy
2. Eine Datei namens “nosync.fdi” darin erzeugen (vi /usr/share/hal/fdi/policy/95userpolicy/nosync.fdi) und darin folgenden Inhalt anlegen:
   <?xml version=”1.0″ encoding=”UTF-8″?>
   <deviceinfo version=”0.2″>
   <device>
   <!– disable sync for mount –>
   <match key=”block.is_volume” bool=”true”>
   <match key=”volume.fsusage” string=”filesystem”>
   <match key=”volume.uuid” string=”==UUID==”>
   <merge key=”volume.policy.mount_option.sync”
   type=”bool”>false</merge>
   </match>
   </match>
   </match>
   </device>
   </deviceinfo>
3. Ausführen von “lshal“. Die Passage im unter Punkt 2. aufgeführten Text die hier temporär mit “==UUID==” befüllt ist, mit der Ausgabe dieses Befehls ersetzen.
4. HAL Daemon neu starten (rhal restart)

Ich hoffe dieses hilft einigen von Euch

Wie immer würde ich mich freuen, wenn ihr einen kurzen Kommentar eintragen würdet!

Achja, wie immer der Hinweis: Wer sich über diese “merkwürdigen” Bezeichnungen wie “MebiByte”, GibiByte”, etc. wundert, dem sein mein Artikel über Binärpräfixe als Lektüre ans Herz gelegt

Und wieder etwas gelernt:

Ich habe versucht ein Source RPM auf einem unserer Server zu installieren. Dieses scheiterte mit folgender Meldung:

error: Installed (but unpackaged) file(s) found:
/usr/BerkeleyDB/3.1/lib/libdb-3.1.la
/usr/BerkeleyDB/3.1/lib/libdb_cxx-3.1.la

RPM build errors:
Installed (but unpackaged) file(s) found:
/usr/BerkeleyDB/3.1/lib/libdb-3.1.la
/usr/BerkeleyDB/3.1/lib/libdb_cxx-3.1.la

Inzwischen habe ich herausgefunden, das dieses ein Sicherheitsmechanismus ist, damit Dateien, die in einem Verzeichnis liegen, in die Dateien gleichen Namens aus dem RPM Paket installiert werden würden, nicht überschrieben werden.
Normalerweise lassen sich bei der Installation eines RPM Paketes Dateien ja zuvor installierten Paketen zuordnen. Installiert man jedoch nun etwas per Hand aus dem Sourcecode, ist es dem RPM System ja nicht möglich, diese Dateien einem Programm zuzuordnen. Daher bricht es lieber ab.

Hat man nun festgestellt, das die angemerkten Dateien überschrieben werden können, fügt man den kompletten Pfad mit den Dateinamen der Programmname.spec – Datei hinzu.
.spec Dateien sind eine Art Bauanleitung, um Sourcecode zu RPM Paketen zu verpacken.
Nachdem die Installation bereits einmal mit der obigen Fehlermeldung fehlgeschlagen ist, befindet sich unter /usr/src/packages/ das entpackte RPM Paket. Unter SPEC steht die .spec Datei, unter BUILD die Sourcen, etc.

Beim obigen Beispiel editieren wir also die Datei /usr/src/packages/SPECS/db3-cxx.spec .
Hier suchen wir nach einem Abschnitt, der %files heisst. Darunter fügen wir die angemeckerten Dateien ein, also:

Vorher:

%files
%defattr(-,root,root)
%{_bindir}/*
%{_libdir}/*.so

Nachher:

%files
%defattr(-,root,root)
%{_bindir}/*
%{_libdir}/*.so
/usr/BerkeleyDB/3.1/lib/libdb-3.1.la
/usr/BerkeleyDB/3.1/lib/libdb_cxx-3.1.la

Nun können wir das ganze nicht einfach erneut über das Source-RPM installieren, da unsere Änderungen sonst direkt wieder überschrieben würden.
Stattdessen wechseln wir in das Verzeichnis /usr/src/packages und führen folgenden Befehl aus:

rpmbuild -ba SPECS/db3-cxx.spec

ACHTUNG:

bei manchen RPM basierenden Distributionen/-versionen gibt es das rpmbuild Programm nicht. Früher wurde der obige Befehl über rpm aufgerufen. Probiert in diesem Fall also:

rpm -ba SPECS/db3-cxx.spec

Hierdurch wird das RPM Binär- und Quellpaket neu gebaut.
Diese Pakete liegen dann in den Unterverzeichnissen SRPMS und RPMS/architektur/ von /usr/src/packages .

Diese können nun Problemlos, wie ein offizielles RPM Paket, installiert werden:

rpm -Uvh /usr/src/packages/RPMS/i586/db3-cxx*.rpm