e2fsprogs versus util-linux-ng

[hermann72pb]

Hallo zusammen,

es ist allgemein bekannt, dass blkid von e2fsprogs (und neuerdings auch von busybox) allgemein Probleme auf älteren Boxen aufweist. Dazu hatte ich mich im Netz umgeschaut und einige mögliche Patches und Lösungen gesehen, die dagegen wirken könnten. Eine nähere Betrachtung zeigte jedoch, dass diese Lösungen nicht unbedingt zu e2fsprogs passen, denn angeblich gibt es noch eine Alternative für e2progfs, die "util-linux-ng" heißt und unter
http://www.kernel.org/pub/linux/utils/util-linux-ng/
zu finden ist. Dieses Package scheint etwas intensiever und aktiver gepflegt zu sein, als e2fsprogs von
http://e2fsprogs.sourceforge.net/
Ein Vergleich der blkid.c (nur als Beispiel) zeigte bei mir deutliche Differenzen.
In beiden Paketen finden sich ähnliche Utiliten und Bibliotheken, die allerdings unter util-linux-ng deutlich weiter gepflegt scheinen als unter e2fsprogs. Was auf jeden Fall fest steht: blkid wurde durch beide Pakete unterschiedlich geforked und wird nach meinem Kenntnis zwischen den beiden nicht synchronisiert. Wenn busybox noch ein weiteres Fork von blkid treibt, dann haben wir ganz verloren.

Meine Fragen:
1. Warum nutzen wir e2fsprogs und nicht util-linux-ng?
2. Ist e2fsprogs eine spezielle Anpassung von util-linux-ng für "kleineres Linux"? Oder wie sieht da die historische Reihenfolge?
3. Gibt es eine eigene Projektseite von blkid, wo sich die beiden Pakete bedienen? Oder wie sieht da die Hierarchie aus?

Meine Fragen adressieren sich in erster Linie in Richtung "alter Hasen" unter uns, die sich schon seit ewigen Zeiten mit diversen Linuxsystemen beschäftigen.

Übrigens, e2fsprogs gibt es seit kurzem als Version 1.41.10. Kann das bitte jemand einpflegen? Zwar wird es anscheinend unsere Probleme nicht lösen, aber wer weiß.

Ich schaue mich um, ob ich util-linux-ng cross-kompiliert bekomme.

MfG

 

[olistudent]

Was genau hast du eigentlich gegen fstyp? Die 8kb sind unschlagbar. Welche Dateisysteme erkennt es denn nicht? Vielleicht können wir es erweitern. Zum mounten by label oder uuid könnten wir ja die neuen busybox utils nutzen.

MfG Oliver

 

[hermann72pb]

Ich habe nichts gegen fstyp generell, es erkennt aber eine ganze Menge nicht. Zu einem die flash-internen-Systeme (jffs, squashfs), dann hat er Probleme mit fuse-spezifischen Dateisystemen (ntfs, davfs) usw. Was übrig bleibt, sind vielleicht ext und fat. swap kann er -glaube ich- auch nicht. Also, ich hatte damit mehr Probleme als nutzen. Und allene dafür, um den Typ der 2-3 Dateisysteme zu erkennen sind die 8 kB meiner Meinung nach zu viel. Das Blöde ist auch: Er sagt gar nichts, wenn er das Dateisystem nicht kennt. Natürlich, geht es über diverse Umwege, die Informationen trotzdem zu bekommen. Nur, beim blkid genügt dafür nur einen Aufruf und zusätzlich zu fstyp musst du noch mount aufrufen und filtern und ggf. noch zusätzlich unter Devices schauen.

MfG

 

[olistudent]

jffs und squashfs kennt er nicht, davfs auch nicht. Aber ntfs sollte fstyp erkennen und swap auch.
fstyp war ursprüngliche ja auch nur zum Mounten gedacht und da tut es genau was es soll. Es gibt den Typ des angegebenen Dateisystems aus.

Gruß
Oliver

 

[olistudent]

Ich hab mir fstyp nochmal genauer angesehen. Squashfs und jffs2 Unterstützung ist kein Problem. Aber ich glaube du hast da mit davfs2 was verwechselt. Wie soll den fstyp davfs2 erkennen können? Das ist kein Dateisystem, dass ein darunter liegendes Blockdevice hat.

/var/mod/root # ./fstyp /dev/mtdblock0
squashfs
/var/mod/root # ./fstyp /dev/mtdblock1
EVA kernel
/var/mod/root # ./fstyp /dev/mtdblock2
unknown filesystem
/var/mod/root # ./fstyp /dev/mtdblock5
jffs2

MfG Oliver

 

[hermann72pb]

Bei einer meinen Boxen mit Busybox 12.4 sieht es so aus:

/var/mod/root # mount
rootfs on / type rootfs (rw)
/dev/root on / type squashfs (ro)
dev on /dev type tmpfs (rw,nosuid)
proc on /proc type proc (rw,nosuid,nodev,noexec)
tmpfs on /var type tmpfs (rw)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec)
/dev/mtdblock5 on /data type jffs2 (rw)
usbfs on /proc/bus/usb type usbfs (rw)
/dev/sda1 on /var/media/ftp/SYSTEM type ext2 (rw,noatime,nodiratime)
/dev/sda2 on /var/media/ftp/FAT type vfat (rw,fmask=0000,dmask=0000,codepage=cp437,iocharset=iso8859-1)
/dev/sda4 on /var/media/ftp/DATA type ext2 (rw,noatime,nodiratime)
https://sd2dav.1und1.de/ on /var/media/ftp/Onlinespeicher type fuse (rw,nosuid,nodev,user_id=0,group_id=0,allow_other,max_read=28672)

/var/mod/root # blkid /dev/sda1
/dev/sda1: LABEL="SYSTEM" UUID="bdfb61e8-7fcf-a242-408a-70a85445e21c" TYPE="ext2"
/var/mod/root # fstyp /dev/sda1
ext2
/var/mod/root # blkid /dev/sda2
/dev/sda2: LABEL="FAT" UUID="CA55-631F" TYPE="vfat"
/var/mod/root # fstyp /dev/sda2
vfat
/var/mod/root # blkid /dev/sda3
/dev/sda3: TYPE="swap"
/var/mod/root # fstyp /dev/sda3
swap
/var/mod/root # blkid /dev/sda4
/dev/sda4: LABEL="DATA" UUID="b3166ed8-0034-90e3-fea4-8693a5f71252" TYPE="ext2"
/var/mod/root # fstyp /dev/sda4
ext2
/var/mod/root # blkid /dev/root
/var/mod/root # fstyp /dev/root
/var/mod/root # blkid https://sd2dav.1und1.de/
/var/mod/root # fstyp https://sd2dav.1und1.de/
/var/mod/root # blkid /dev/mtdblock5
/var/mod/root # fstyp /dev/mtdblock5

Aber wo du Recht hast, da hast du Recht: blkid ist nicht besser als fstyp: In der Version erkennen beide nicht jffs2. Warum auch immer. Ich bin dann wahrscheinlich in der mounted.cgi einen komplett anderen Weg gegangen und hatte mir letztendlich die Ausgaben von mount mit read ausgelesen. Ursprünglich war meine Idee dort dafür fstyp zu benutzen, aber wie ich schon sagte, scheiterte ich damals.

Momentan wird fstyp nur an einer Stelle in libmodmount.sh benutzt und auch dort redundant. D.h. wenn blkid mit am Board ist, dann braucht man nicht zwangsläufig fstyp. Andererseits wenn man blkid nicht wählen würde, dann bräuchte man fstyp, damit libmodmoun.sh ihre Prüfung und Unterscheidung machen kann.

Meine Vorschläge auf fstyp zu verzichten kamen eher daher, dass man diese Querabhängigkeiten nicht ganz einfach und vernünftig mit menuconfig realisieren kann. Wenn man blkid zwangsläufig voraussetzt, dann wird es mit den Querabhängigkeiten deutlich einfacher. Und ich bin mir nicht so ganz sicher, ob es momentan doch nicht eine Lücke existiert, dass man beides, blkid und fstyp abwählen kann und dass dan FREETZMOUNT auf die nase fällt.

In diesem Thread hier sollte es dagegen nicht primär um diesen Glaubenskrieg zwischen blkid und fstyp gehen, sondern darum die util-linux-ng bezüglich FREETZ zu bewerten. In dem Package gibt es deutlich mehr als blkid drin und wie ich schon mehrmals sagte scheint es deutlich besser gepflegt zu sein, als e2fsprogs. Deswegen bräuchte ich hier eine Aussage von jemanden, der vielleicht aus der "großen" Linux-Welt sich mit den ng-utils auskennt. Eine Aussage der Art, dass es gar nicht zu unseren Kernels passt oder sich gar nicht für kleinere Boxen eignet würde z.B. auch eine Klarheit schaffen.

Ich würde es mir annehmen ng-utils anzuschauen und versuchen zu portieren. Leider wird es aber in den nächsten Wochen nicht passieren. Von daher, entweder bleibt es hier so liegen, oder jemand schaut sich es vorher an.

MfG

 

[er13]

hab' mal das Paket erstellt, denk' aber nicht, dass es uns weiter bringen wird. Konnte keinen Unterschied zu der e2fsprogs' Version feststellen. findfs bleibt bei mir hängen...

 

[olistudent]

@er13
Hast du mal die Größe der Dateien angeschaut? Ich befürchte, dass die noch größer als die von e2fsprogs sind?

MfG Oliver

 

[er13]

genaue Zahlen habe ich jetzt nicht im Kopf, sind aber deutlich größer ~150-170KB, libc/libgcc sind dynamisch gelinkt, rest statisch

Edit: habe mich geirrt, blkid - 134KB, findfs - 122KB

Edit2:

Übrigens, e2fsprogs gibt es seit kurzem als Version 1.41.10. Kann das bitte jemand einpflegen? Zwar wird es anscheinend unsere Probleme nicht lösen, aber wer weiß.

done In Bezug auf blkid hat sich nichts geändert, minimale Änderung in blkid/probe.c adressiert ein anderes Problem...

 

[hermann72pb]

@er13: Ich war leider länger nicht erreichbar, deswegen melde mich erst jetzt. Ich werde mir das Ding nach deinem Patch die Tage bauen und testen.

Zu findfs. Bleibt es bei dir bei der 7170 hängen? Wie sieht es bei blkid-Aufruf ohne Parameter? Dann scheint das Problem mit den älteren Boxen damit doch nicht gelöst sein. Wahrscheinlich greift findfs auf die gleichen Routinen wie blkid.

Ich melde mich, wenn ich weiter bin.

MfG

 

[RalfFriedl]

Es gibt Firmware-Versionen, wo ein Programm beim Lesen von Geräte-Dateien (vermutlich /dev/mtdblock0) hängen bleibt, und sich auch mit kill nicht mehr beenden läßt. Das ist ein Fehler im Kernel und hat nichts damit zu tun, welches Programm man verwendet.

 

[olistudent]

Es passiert mit dem gleichen Kernel auf einer 3170 nicht. Könnte also damit zusammenhängen, dass die Flashaufteilung bei einer 7170 anders ist.

MfG Oliver

 

[hermann72pb]

Hast du weitere Infos dazu, Ralf? Dann bitte her damit! Vielleicht weißt du, wie der Fehler heißt, oder hilfst uns mit ein Paar Suchbegriff-Ideen, wonach und wo wir weiter suchen könnten.
Wir haben doch Kernel-Quellen. Vielleicht können wir dies irgendwie patchen. Klar, dass man hierfür "replace kernel" wählen muss. Aber wenn es eine Lösung ist, warum nicht. Bis jetzt bin ich davon ausgegangen, dass blkid an sich hängen bleibt. Dass es mit kernel zu tun hat, wusste ich gar nicht.

@Oliver:
Wie sieht bei deiner 3170 /proc/mtd aus?
Auf meiner 7170 sieht es so aus:

/proc # cat mtd
dev:    size   erasesize  name
mtd0: 00800000 00010000 "phys_mapped_flash"
mtd1: 006c7f00 00010000 "filesystem"
mtd2: 00770000 00010000 "kernel"
mtd3: 00010000 00010000 "bootloader"
mtd4: 00040000 00010000 "tffs (1)"
mtd5: 00040000 00010000 "tffs (2)"
mtd6: 00010000 00010000 "jffs2"
mtd7: 00760000 00010000 "Kernel without jffs2"

MfG

 

[RalfFriedl]

Du kannst es einfach ausprobieren mit

# cat /dev/mtdblock[1-9]* > /dev/null 
cat: can't open '/dev/mtdblock10': No such device or address
cat: can't open '/dev/mtdblock6': No such device or address
cat: can't open '/dev/mtdblock7': No such device or address
cat: can't open '/dev/mtdblock8': No such device or address
cat: can't open '/dev/mtdblock9': No such device or address
# cat /dev/mtdblock0 > /dev/null

Das erste Kommando läuft relativ schnell durch, die Meldungen für die nicht vorhandenen Partitionen sind nachvollziehbar.
Das zweite Kommando bleibt bei mir hängen, es läßt sich nicht mehr stoppen. Auf der Konsole kommt eine Meldung von einem Kernel-Fehler.
Es kommt hier nicht darauf an, ob man cat, dd, findfs, blkid oder was auch immer verwendet, um /dev/mtdblock0 zu lesen.

/proc/mtd sieht bei mir so aus:

# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00800000 00010000 "phys_mapped_flash"
mtd1: 006cab00 00010000 "filesystem"
mtd2: 00770000 00010000 "kernel"
mtd3: 00010000 00010000 "bootloader"
mtd4: 00040000 00010000 "tffs (1)"
mtd5: 00040000 00010000 "tffs (2)"

Da wir die Kernel-Quellen haben, sollte es möglich sein, den Fehler zu finden. Die Frage ist, ob sich die Mühe dafür lohnt. Willst Du bei den Funktionen, die das nutzen sollen, dazuschreiben, daß sie nur mit Replace Kernel funktionieren?

 

[hermann72pb]

Ok, deine Experimente bestätigen nämlich das Verhalten von meiner Beobachtung mit blkid. Dort führt ebenfalls der Aufruf von blkid ohne Parameter (was heißen soll: Such alles und überall) zum Aufhängen.
Ich würde sagen, dass der bessere Weg wäre auf den Aufruf ohne Parameter (a-la "such alles") zu verzichten oder einen wrapper um blkid und co zu schreiben.

Zu den util-linux-ng: Ich werde mir gleich die Binaries kompilieren und damit auf der Box etwas rumspielen.

MfG

 

[RalfFriedl]

Als Ergänzung dazu, ohne einen Fehler im Kernel kann ein Programm zwar in eine Endlos-Schleife kommen, aber es kann nicht passieren, daß man das Programm nicht mehr stoppen kann.

 

[hermann72pb]

Einige Infos aus meinen Untersuchungen. Ich poste hier einfach die Ausgaben, damit jeder vergleichen kann:

/var/mod/root # ls -l /usr/sbin/blkid
-rwxr-xr-x    1 root     root        49240 Mar 20 11:52 /usr/sbin/blkid
/var/mod/root # ls -l /var/media/ftp/SYSTEM/test/blkid-ng
-rwxr-xr-x    1 root     root       134876 Mar 20 13:43 /var/media/ftp/SYSTEM/test/blkid-ng
/var/mod/root # blkid --help
blkid: invalid option -- -
blkid 1.0.0 (12-Feb-2003)
usage:  blkid [-c <file>] [-ghlLv] [-o format] [-s <tag>] [-t <token>]
    [-w <file>] [dev ...]
        -c      cache file (default: /etc/blkid.tab, /dev/null = none)
        -h      print this usage message and exit
        -g      garbage collect the blkid cache
        -s      show specified tag(s) (default show all tags)
        -t      find device with a specific token (NAME=value pair)
        -l      lookup the the first device with arguments specified by -t
        -v      print version and exit
        -w      write cache to different file (/dev/null = no write)
        dev     specify device(s) to probe (default: all devices)
/var/mod/root # blkid-ng --help
blkid-ng: invalid option -- -
blkid from util-linux-ng 2.17.1 (libblkid 2.17.0, 22-Feb-2010)
Usage:
  blkid -L <label> | -U <uuid>

  blkid [-c <file>] [-ghlLv] [-o format] [-s <tag>]
        [-t <token>] [-w <file>] [dev ...]

  blkid -p [-O <offset>] [-S <size>] [-o format] <dev> [dev ...]

Options:
  -c <file>   cache file (default: /etc/blkid.tab, /dev/null = none)
  -h          print this usage message and exit
  -g          garbage collect the blkid cache
  -o <format> output format; can be one of:
              value, device, list, udev or full; (default: full)
  -s <tag>    show specified tag(s) (default show all tags)
  -t <token>  find device with a specific token (NAME=value pair)
  -l          lookup the the first device with arguments specified by -t
  -L <label>  convert LABEL to device name
  -U <uuid>   convert UUID to device name
  -v          print version and exit
  -w <file>   write cache to different file (/dev/null = no write)
  <dev>       specify device(s) to probe (default: all devices)

Low-level probing options:
  -p          switch to low-level mode (bypass cache)
  -S <bytes>  overwrite device size
  -O <bytes>  probe at the given offset
  -u <list>   filter by "usage" (e.g. -u filesystem,raid)

Der blkid-ng hat sicherlich einige Optionen mehr zu bieten, wie ich auch befürchtet hatte. Einiges davon kann man auch bei uns verwenden. Und Einiges wird dadurch deutlich schneller und ohne irgendwelche grep/sed-Tricks funktionieren. Die Frage ist natürlich, ob es uns Wert ist, dass das Ding 134kB anstatt von 50kB vom alten blkid wiegt.

Zum Aufhängen: Der Aufruf von findfs-ng endet tatsächlich darin, dass es sich weder ^C noch irgendwie anders killen lässt:

 1801 root      1432 S    dropbear -p 22 -R
 1857 root      1620 S    httpd -P /var/run/webcfg-wol.pid -p 82 -c /mod/etc/httpd-wol.conf -h /mod/pkg/wol/usr/mww-wol/ -r Wake-on-LAN
 1971 root      3280 S N  smbd -D -s /mod/etc/smb.conf
 1973 root      2512 S    nmbd -D -s /mod/etc/smb.conf
 2029 root      1436 S    init
[B][COLOR="Red"] 2748 root         0 SW   [findfs-ng]
[/COLOR][/B] 2752 root      1488 S    dropbear -p 22 -R

Es ist allerdings nicht so tragisch, weil die Box danach dennoch zu funktionieren scheint.

Beim blkid von busybox (ohne Parameter) war das Aufhängenverhalten am Schlimmsten. Man konnte der Box danach nur den Stecker ziehen.
Bei blkid von e2fsprogs war es ohne Parameter auch ziemlich übel. Killen und ^C ging nicht. Killen aus einer zweiten Dropbear-Session auch nicht. Irgendwann mal war die Box so langsam und nur mit sich beschäftigt, dass auch hier nur Steckerziehen half.
Bei blkid-ng ist das Verhalten deutlich besser. Zwar hängt sich es auch, wenn man es ohne Parameter aufruft, dafür kann es aber mit einem simplen ^C beendet werden (und ich vermute per kill auch).
Deswegen würde ich vorschlagen, util-linux-ng erstmal so in den trunk als "testing" aufzunehmen und weitere Experimente damit durchzuführen.

MfG

 

[RalfFriedl]

Bei blkid-ng ist das Verhalten deutlich besser. Zwar hängt sich es auch, wenn man es ohne Parameter aufruft, dafür kann es aber mit einem simplen ^C beendet werden

Das ist interessant, und hat vielleicht auch damit zu tun, daß ps beim Status "SW" anzeigt und nicht "D".
Kannst Du mal ein strace davon machen?

 

[hermann72pb]

den findfs-ng kann ich aber aus diesem SW-Status heraus nicht killen. blkid zeigt einen S-Status:

  409 root      1488 S    dropbear -p 22 -R
  410 root      1448 S    -sh
  444 root      1104 S    blkid-ng

und lässt sich danach entweder mit ^C beenden oder per kill 444 aus einer anderen Dropbear-Session:

/var/mod/root # kill 444

Danach sieht man in dem Fenster, wo blkid vorher hing:

/var/mod/root # blkid-ng


Terminated
/var/mod/root #
/var/mod/root #
/var/mod/root #

Strace mache ich auch bei Gelegenheit, allerdings mache ich es ohne replace-kernel und daher auf so einer Art "lite"-Weise.

EDIT:
habe doch blkid-ng zum Aufhängen gebracht:

/var/mod/root # blkid-ng /dev/mtd0

Jetzt lässt er sich nicht mit ^C beenden. Status:

  446 root         0 DW   [blkid-ng]
  447 root      1432 R    ps
/var/mod/root # kill 446
/var/mod/root # ps | grep blkid-ng
  446 root         0 DW   [blkid-ng]

Also das altbekannte Verhalten. Allerdings scheint es irgendwie besser abgefangen zu sein, wenn man es ohne Parameter ausführt...


EDIT2: Ich hatte mir bezüglich blkid die beiden Sources von blkid.c verglichen. Ich bin da zwar kein großartiger Experte in Sachen cross-Kompilieren, aber ich kann mir die Übergröße von blkid-ng gegenüber von blkid von e2fsprogs alleine durch Verbesserungen im Code nicht erklären. So viel ist es meiner Meinung nach doch wohl nicht. Kann es sein, dass wir bei ng-Variante noch an Precompiler-Variablen tunen könnten, um die Größe auf einen vernünftigen Maß zu bringen? Mir scheint es so zu sein, als ob da noch vieles statich gelinkt und einfach mit includet wird, was man nicht unbedingt braucht. Auf der anderen Seite scheint ng-Fork doch etwas weiter zu sein, wenn man schon alleine beide blkid.c gegeneinader vergleicht.

MfG

 

[er13]

Deswegen würde ich vorschlagen, util-linux-ng erstmal so in den trunk als "testing" aufzunehmen und weitere Experimente damit durchzuführen.

hab' mal auf Version 2.17.2 upgedated und eingecheckt