[gelöst] Samba (freetz-trunk) unter winXP: "Datenträger voll"

[caldir65]

Hallo,

hm, da kommt bei mir recht wenig:

christoph@medion2009:~/Downloads/freetz-trunk$ toolchain/target/bin/mipsel-linux-objdump -dr source/target-mipsel_uClibc-0.9.*/samba-3.0.*/source/lib/fsusage.o

source/target-mipsel_uClibc-0.9.29/samba-3.0.37/source/lib/fsusage.o:     file format elf32-tradlittlemips

Disassembly of section .text:

00000000 <sys_fsusage>:
   0:   03e00008        jr      ra
   4:   2402ffff        li      v0,-1
        ...
christoph@medion2009:~/Downloads/freetz-trunk$

Gruß, Christoph

 

[olistudent]

Ich muss nicht verstehen warum sich das configure hier unterschiedlich verhält oder? Probier mal bitte folgende Änderung und nach einem "Neubau" nochmal den objdump Befehl.

Index: make/samba/samba.mk
===================================================================
--- make/samba/samba.mk (Revision 5629)
+++ make/samba/samba.mk (Arbeitskopie)
@@ -28,6 +28,11 @@
 $(PKG)_CONFIGURE_ENV += ac_cv_func_prctl=no
 $(PKG)_CONFIGURE_ENV += SMB_BUILD_CC_NEGATIVE_ENUM_VALUES=yes
 
+ifeq ($(strip $(FREETZ_TARGET_LFS)),y)
+$(PKG)_CONFIGURE_ENV += samba_cv_have_longlong=yes
+$(PKG)_CONFIGURE_ENV += fu_cv_sys_stat_statvfs64=yes
+endif
+
 $(PKG)_CONFIGURE_OPTIONS += --disable-swat
 $(PKG)_CONFIGURE_OPTIONS += --disable-cups
 $(PKG)_CONFIGURE_OPTIONS += --disable-iprint

MfG Oliver

 

[RalfFriedl]

Das ist genau der Grund für die Fehlermeldung von #1. Die Funktion tut überhaupt nichts, außer "return -1", was nachher als "sys_fsusage() failed" gemeldet wird.

Aus irgend einem Grund erkennt bei Dir das Samba configure nicht die richtige Einstellung für fu_cv_sys_stat_statvfs.

Was sagt

grep fu_cv_sys_stat_statvfs source/target-mipsel_uClibc-0.9.29/config.cache

Probier mal bitte folgende Änderung

Bei mir erkennt configure fu_cv_sys_stat_statvfs=yes, was ausreicht. Da die 64-Bit Versionen sowieso nur auf die normale Version umgesetzt werden, ist es einfacher und vielleicht auch sicherer, nur fu_cv_sys_stat_statvfs zu setzen, unabhängig von LFS.

Ich würde aber zuerst empfehlen, confgi.cache zu löschen und zu sehen, ob configure wieder nicht das richtige Ergebnis findet.

libgcc hat auch soft-float, so dass der FPU Kernel EMU normalerweise nicht genutzt wird. Oder was meintest du jetzt?

Ich meinte, daß in Deiner Funktion adjust_blocks direkt FPU Befehle verwendet werden, während bei mir Aufrufe von Library Funktionen drin sind, und daher die Funktion deutlich länger ist. Das hat weniger mit der uClibc-Konfiguration zu tun, sondern eher mit den Flags beim Übersetzen des Programms. Vermutlich habe ich meinen Samba erstellt, als noch soft-float eingestellt war.

 

[olistudent]

Bei mir war "HAVE_EXPLICIT_LARGEFILE_SUPPORT" nicht "aktiviert", da der Test auf "samba_cv_have_longlong" cross zurückgibt. Nachdem ich das samba_cv_have_longlong=yes gesetzt hatte sah meine sys_fsusage Funktion auch aus wie die von caldir65. Komischerweise war vorher HAVE_STATVFS64=yes gesetzt, danach nicht mehr. Ein Blick in die config.h von AVMs Samba offenbarte die Variablen wie ich sie jetzt gesetzt habe.
Ist halt die Frage, ob das noch andere Auswirkungen hat?

MfG Oliver

 

[caldir65]

@Ralf

christoph@medion2009:~/Downloads/freetz-trunk$ grep fu_cv_sys_stat_statvfs source/target-mipsel_uClibc-0.9.29/config.cache
fu_cv_sys_stat_statvfs64=${fu_cv_sys_stat_statvfs64=cross}
fu_cv_sys_stat_statvfs=${fu_cv_sys_stat_statvfs=no}
christoph@medion2009:~/Downloads/freetz-trunk$

@oliver

Deine Änderung folgt später - bin nur kurz zu Hause

 

[olistudent]

Ich würde aber zuerst empfehlen, confgi.cache zu löschen und zu sehen, ob configure wieder nicht das richtige Ergebnis findet.

Probier bitte erstmal das aus.

make samba-dirclean
rm source/target-mipsel_uClibc-0.9.29/config.cache
make samba-configured
grep fu_cv_sys_stat_statvfs source/target-mipsel_uClibc-0.9.29/config.cache

MfG Oliver

 

[RalfFriedl]

Der HAVE_EXPLICIT_LARGEFILE_SUPPORT sollte normalerweise nicht benötigt werden. Anscheinend werden mit dieser Option Funktionen wie stat64, open64, usw. verwendet. Bei Verwendung der entsprechenden Compiler-Optionen werden automatisch 64-Bit Funktionen verwendet, auch wenn man im Programm stat, open, usw. aufruft.
Es könnte aber sein, daß Samba ansonsten davon ausgeht, daß 64-Bit Zugriffe nicht möglich wären, obwohl sie es in Wirklichkeit sind. Ich habe bei mir keine so großen Dateien drauf um es auszuprobieren.

Bei mir kommt wie gesagt ein lauffähiges Samba heraus, ohne daß man zusätzliche Optionen übergeben muß, einschließlich des Aufrufs von statvfs64 und nicht statvfs.

Seltsam, daß bei gesetztem samba_cv_have_longlong HAVE_STATVFS64 nicht mehr gesetzt ist. STAT_STATVFS bzw. STAT_STATVFS64 ist auf jeden Fall für die Funktion entscheidend:

source/lib/fsusage.c:125
#if defined(STAT_STATVFS) || defined(STAT_STATVFS64)            /* SVR4 */

 

[olistudent]

@Ralf

#if defined __GLIBC__ && !defined __BEOS__
Do not use statvfs on systems with GNU libc, because that function stats
all preceding entries in /proc/mounts, and that makes df hang if even
one of the corresponding file systems is hard-mounted, but not available.
statvfs in GNU libc on BeOS operates differently: it only makes a system
call.
#endif

Es sieht so aus als würde das mc Paket den Wert fu_cv_sys_stat_statvfs=no ausgeben.

Was denkst du über den Kommentar?

MfG Oliver

 

[caldir65]

Probier bitte erstmal das aus.

Keine Änderung ...

christoph@medion2009:~/Downloads/freetz-trunk$ grep fu_cv_sys_stat_statvfs source/target-mipsel_uClibc-0.9.29/config.cache
fu_cv_sys_stat_statvfs64=${fu_cv_sys_stat_statvfs64=cross}
fu_cv_sys_stat_statvfs=${fu_cv_sys_stat_statvfs=yes}
christoph@medion2009:~/Downloads/freetz-trunk$

 

[RalfFriedl]

Es stimmt, daß statvfs einen stat-Aufruf für jedes Dateisystem macht, genauer gesagt solange, bis das richtige Dateisystem gefunden wird. Das ist für die Verwendung bei Samba unnötig. Das ist genau das, was ich in #13 gemeint hatte.

Die Lösung dafür ist aber nicht, so zu tun, als wäre die Funktion nicht vorhanden. Besser ist es, in samba, in mc, und wo auch immer sonst, bevorzugt die Funktion statfs aufzurufen. Die man-page von statfs sagt zwar

The kernel has system calls statfs, fstatfs, statfs64, fstatfs64 to support this library call.
...
LSB has deprecated the library calls [f]statfs() and tells us to use [f]statvfs() instead.

Ich sehe aber keinen Grund dafür, auf die direkten Aufrufe zu verzichten. Einerseits sind die Systemaufrufe im Kernel vorhanden (statfs64 in meinem Kernel allerdings nicht).
Zum anderen macht die Funktion statvfs noch etliche Aufrufe von stat, deren Ergebnis in vielen Fällen niemanden interessiert.

Ich würde es mal mit fu_cv_sys_stat_statfs2_bsize=yes probieren. Leider testet Samba zuerst auf statvfs und verwendet es unabhängig vom Wert von fu_cv_sys_stat_statfs2_bsize.

Mit fu_cv_sys_stat_statvfs=no, fu_cv_sys_stat_statfs2_bsize=yes komme ich zu einem funktionierenden Samba, allerdings finde ich es nicht schön, zu behaupten, daß statvfs nicht vorhanden wäre, zumal das auch in der config.cache landet.

Ich würde diese Änderung an config.in machen, allerdings wird configure nicht neu aus configure.in erstellt. Die Änderung ist zum Einen, daß zuerst auf statfs geprüft wird, und zum Anderen, daß nur ein Link-Test gemacht wird und nicht versucht wird, das Testprogramm aufzurufen.

Eine Verschiebung in configure in Verbindung mit einem vorab gesetzten fu_cv_sys_stat_statfs2_bsize=yes würde aber auch funktionieren.

--- source/target-mipsel_uClibc-0.9.29/samba-3.0.37/source/configure.in
+++ source/target-mipsel_uClibc-0.9.29/samba-3.0.37/source/configure.in
@@ -4997,6 +4997,37 @@
 AC_CHECKING(how to get filesystem space usage)
 space=no

+if test $space = no; then
+# AIX, prefer statfs on Linux
+  AC_MSG_CHECKING([for two-argument statfs with statfs.bsize dnl
+member (AIX, 4.3BSD)])
+  AC_CACHE_VAL(fu_cv_sys_stat_statfs2_bsize,
+  [AC_TRY_LINK([
+#ifdef HAVE_SYS_PARAM_H
+#include <sys/param.h>
+#endif
+#ifdef HAVE_SYS_MOUNT_H
+#include <sys/mount.h>
+#endif
+#ifdef HAVE_SYS_VFS_H
+#include <sys/vfs.h>
+#endif
+  main ()
+  {
+  struct statfs fsd;
+  fsd.f_bsize = 0;
+  exit (statfs (".", &fsd));
+  }],
+  fu_cv_sys_stat_statfs2_bsize=yes,
+  fu_cv_sys_stat_statfs2_bsize=no,
+  fu_cv_sys_stat_statfs2_bsize=no)])
+  AC_MSG_RESULT($fu_cv_sys_stat_statfs2_bsize)
+  if test $fu_cv_sys_stat_statfs2_bsize = yes; then
+    space=yes
+    AC_DEFINE(STAT_STATFS2_BSIZE,1,[Whether statfs requires two arguments and struct statfs has bsize property])
+  fi
+fi
+
 # Test for statvfs64.
 if test $space = no; then
   # SVR4
@@ -5076,37 +5107,6 @@
 fi

 if test $space = no; then
-# AIX
-  AC_MSG_CHECKING([for two-argument statfs with statfs.bsize dnl
-member (AIX, 4.3BSD)])
-  AC_CACHE_VAL(fu_cv_sys_stat_statfs2_bsize,
-  [AC_TRY_RUN([
-#ifdef HAVE_SYS_PARAM_H
-#include <sys/param.h>
-#endif
-#ifdef HAVE_SYS_MOUNT_H
-#include <sys/mount.h>
-#endif
-#ifdef HAVE_SYS_VFS_H
-#include <sys/vfs.h>
-#endif
-  main ()
-  {
-  struct statfs fsd;
-  fsd.f_bsize = 0;
-  exit (statfs (".", &fsd));
-  }],
-  fu_cv_sys_stat_statfs2_bsize=yes,
-  fu_cv_sys_stat_statfs2_bsize=no,
-  fu_cv_sys_stat_statfs2_bsize=no)])
-  AC_MSG_RESULT($fu_cv_sys_stat_statfs2_bsize)
-  if test $fu_cv_sys_stat_statfs2_bsize = yes; then
-    space=yes
-    AC_DEFINE(STAT_STATFS2_BSIZE,1,[Whether statfs requires two arguments and struct statfs has bsize property])
-  fi
-fi
-
-if test $space = no; then
 # SVR3
   AC_MSG_CHECKING([for four-argument statfs (AIX-3.2.5, SVR3)])
   AC_CACHE_VAL(fu_cv_sys_stat_statfs4,

christoph@medion2009:~/Downloads/freetz-trunk$ grep fu_cv_sys_stat_statvfs source/target-mipsel_uClibc-0.9.29/config.cache
fu_cv_sys_stat_statvfs64=${fu_cv_sys_stat_statvfs64=cross}
fu_cv_sys_stat_statvfs=${fu_cv_sys_stat_statvfs=[B]no[/B]}
christoph@medion2009:~/Downloads/freetz-trunk$

Keine Änderung ...

christoph@medion2009:~/Downloads/freetz-trunk$ grep fu_cv_sys_stat_statvfs source/target-mipsel_uClibc-0.9.29/config.cache
fu_cv_sys_stat_statvfs64=${fu_cv_sys_stat_statvfs64=cross}
fu_cv_sys_stat_statvfs=${fu_cv_sys_stat_statvfs=[B]yes[/B]}
christoph@medion2009:~/Downloads/freetz-trunk$

Sicher keine Änderung?

 

[olistudent]

Wir haben ein Macro um solche Variablen Paket spezifisch zu machen.
Beispiel:

$(PKG)_CONFIGURE_PRE_CMDS += $(call PKG_MAKE_AC_VARIABLES_PACKAGE_SPECIFIC,header_readline_readline_h)

Wie wäre es das zu nutzen und die 2 Variablen zu setzen? Das Patchen von configure.in würde ich gerne vermeiden.

MfG Oliver

edit: Funktioniert derzeit nur für ac_cv Variablen, also auch nix.

 

[RalfFriedl]

Das kann man ja auch ändern, daß es nicht nur für av_cv Variablen funktioniert.

PKG_MAKE_AC_VARIABLES_PACKAGE_SPECIFIC = $(SED) -i -r $(foreach var,$1,-e 's/($(var))/$(PKG)\1/g' $(if $2,$2,./configure);

Die Zeile ist nicht getestet, sieht aber schon mal viel übersichtlicher aus als die ursprüngliche, und das ohne Shell-Aufrufe.

Sinnvollerweise würde man ac_cv_ ergänzen an den Stellen, wo das Makro aufgerufen wird, auch wenn vermutlich ohne diese Änderung funktionieren würde.

Oder so:

PKG_MAKE_CONF_VARIABLES_PACKAGE_SPECIFIC = $(SED) -i -r $(foreach var,$1,-e 's/($(var))/$(PKG)\1/g' $(if $2,$2,./configure);
PKG_MAKE_AC_VARIABLES_PACKAGE_SPECIFIC = $(call PKG_MAKE_CONF_VARIABLES_PACKAGE_SPECIFIC,$(foreach var,$1,ac_cv_$(var)),$2)

 

[caldir65]

Sicher keine Änderung?

Ups, doch eine kleine Änderung Das kommt davon, wenn man mal eben schnell zwischen Tür und Angel ... Wenn es hilfreich war...

Gruß, Christoph

 

[RalfFriedl]

Es zeigt, daß Samba allein den richtigen Wert findet. Wie Oliver in #28 schreibt, liegt Dein Problem vermutlich daran, daß mc da einen falschen Wert einträgt.
Ich habe im Trunk zwei Änderungen, 5636 und 5637, mit denen grundsätzlich statfs verwendet wird.
Die Verwendung von statfs ist effizienter und sollte von allen Programmen verwendet werden, die nicht die Informationen brauchen, die statvfs zusätzlich liefert.

 

[olistudent]

Sieht gut aus:

$ toolchain/target/bin/mipsel-linux-objdump -rd source/target-mipsel_uClibc-0.9.29/samba-3.0.37/source/lib/fsusage.o |grep statfs
                        78: R_MIPS_CALL16       statfs64

Aber mit diesem FPU-Code muss ich jetzt doch nochmal nachfragen.

00000000 <adjust_blocks>:
   0:   10a60011        beq     a1,a2,48 <adjust_blocks+0x48>
   4:   00000000        nop
   8:   00c5102b        sltu    v0,a2,a1
   c:   10400006        beqz    v0,28 <adjust_blocks+0x28>
  10:   00000000        nop
  14:   00a6001b        divu    zero,a1,a2
  18:   00c001f4        teq     a2,zero,0x7
  1c:   00001012        mflo    v0
  20:   10000009        b       48 <adjust_blocks+0x48>
  24:   70822002        mul     a0,a0,v0
  28:   00c5280a        movz    a1,a2,a1
  2c:   00c5001b        divu    zero,a2,a1
  30:   00a001f4        teq     a1,zero,0x7
  34:   24820001        addiu   v0,a0,1
  38:   00001812        mflo    v1
  3c:   0043001b        divu    zero,v0,v1
  40:   006001f4        teq     v1,zero,0x7
  44:   00002012        mflo    a0
  48:   03e00008        jr      ra
  4c:   00801021        move    v0,a0

Durch welche Library Calls wird der denn bei dir ersetzt? Oder anders: Wo liegt in meiner Toolchain der "Fehler"? Die direkten FPU Befehle werden vom Kernel FPU Emulator abgearbeitet?

MfG Oliver

 

[RalfFriedl]

Es ist kein Fehler. Es liegt am Compiler oder an den Compiler-Optionen.

Meine neue Datei sieht fast genauso wie Deine aus, wobei ich noch GCC 4.3.5 habe.

00000000 <adjust_blocks>:
   0:   10a60010        beq     a1,a2,44 <adjust_blocks+0x44>
   4:   00000000        nop
   8:   00c5102b        sltu    v0,a2,a1
   c:   50400006        beqzl   v0,28 <adjust_blocks+0x28>
  10:   00c5280a        movz    a1,a2,a1
  14:   00a6001b        divu    zero,a1,a2
  18:   00c001f4        teq     a2,zero,0x7
  1c:   00001012        mflo    v0
  20:   10000008        b       44 <adjust_blocks+0x44>
  24:   70822002        mul     a0,a0,v0
  28:   00c5001b        divu    zero,a2,a1
  2c:   00a001f4        teq     a1,zero,0x7
  30:   24820001        addiu   v0,a0,1
  34:   00001812        mflo    v1
  38:   0043001b        divu    zero,v0,v1
  3c:   006001f4        teq     v1,zero,0x7
  40:   00002012        mflo    a0
  44:   03e00008        jr      ra
  48:   00801021        move    v0,a0

Die ältere Version ist mit GCC 4.3.3 erstellt und sieht so aus:

00000000 <adjust_blocks>:
   0:   3c1c0000        lui     gp,0x0
                        0: R_MIPS_HI16  __gnu_local_gp
   4:   27bdffd0        addiu   sp,sp,-48
   8:   279c0000        addiu   gp,gp,0
                        8: R_MIPS_LO16  __gnu_local_gp
   c:   afbf002c        sw      ra,44(sp)
  10:   afb30028        sw      s3,40(sp)
  14:   afb20024        sw      s2,36(sp)
  18:   afb10020        sw      s1,32(sp)
  1c:   afb0001c        sw      s0,28(sp)
  20:   afbc0010        sw      gp,16(sp)
  24:   8fa80040        lw      t0,64(sp)
  28:   8fa90044        lw      t1,68(sp)
  2c:   00809021        move    s2,a0
  30:   14c80003        bne     a2,t0,40 <adjust_blocks+0x40>
  34:   00a09821        move    s3,a1
  38:   10e9002e        beq     a3,t1,f4 <adjust_blocks+0xf4>
  3c:   8fbf002c        lw      ra,44(sp)
  40:   0127102b        sltu    v0,t1,a3
  44:   14400007        bnez    v0,64 <adjust_blocks+0x64>
  48:   8f990000        lw      t9,0(gp)
                        48: R_MIPS_CALL16       __udivdi3
  4c:   14e90013        bne     a3,t1,9c <adjust_blocks+0x9c>
  50:   00c71025        or      v0,a2,a3
  54:   0106102b        sltu    v0,t0,a2
  58:   10400010        beqz    v0,9c <adjust_blocks+0x9c>
  5c:   00c71025        or      v0,a2,a3
  60:   8f990000        lw      t9,0(gp)
                        60: R_MIPS_CALL16       __udivdi3
  64:   00c02021        move    a0,a2
  68:   00e02821        move    a1,a3
  6c:   01003021        move    a2,t0
  70:   0320f809        jalr    t9
  74:   01203821        move    a3,t1
  78:   00720018        mult    v1,s2
  7c:   8fbc0010        lw      gp,16(sp)
  80:   72620000        madd    s3,v0
  84:   00001812        mflo    v1
  88:   02420019        multu   s2,v0
  8c:   00009810        mfhi    s3
  90:   00009012        mflo    s2
  94:   10000016        b       f0 <adjust_blocks+0xf0>
  98:   00739821        addu    s3,v1,s3
  9c:   14400003        bnez    v0,ac <adjust_blocks+0xac>
  a0:   8f990000        lw      t9,0(gp)
                        a0: R_MIPS_CALL16       __udivdi3
  a4:   01003021        move    a2,t0
  a8:   01203821        move    a3,t1
  ac:   26420001        addiu   v0,s2,1
  b0:   01002021        move    a0,t0
  b4:   01202821        move    a1,t1
  b8:   00408021        move    s0,v0
  bc:   0052102b        sltu    v0,v0,s2
  c0:   0320f809        jalr    t9
  c4:   00538821        addu    s1,v0,s3
  c8:   8fbc0010        lw      gp,16(sp)
  cc:   02002021        move    a0,s0
  d0:   8f990000        lw      t9,0(gp)
                        d0: R_MIPS_CALL16       __udivdi3
  d4:   02202821        move    a1,s1
  d8:   00403021        move    a2,v0
  dc:   0320f809        jalr    t9
  e0:   00603821        move    a3,v1
  e4:   8fbc0010        lw      gp,16(sp)
  e8:   00409021        move    s2,v0
  ec:   00609821        move    s3,v1
  f0:   8fbf002c        lw      ra,44(sp)
  f4:   02401021        move    v0,s2
  f8:   02601821        move    v1,s3
  fc:   8fb30028        lw      s3,40(sp)
 100:   8fb20024        lw      s2,36(sp)
 104:   8fb10020        lw      s1,32(sp)
 108:   8fb0001c        lw      s0,28(sp)
 10c:   03e00008        jr      ra
 110:   27bd0030        addiu   sp,sp,48

Man sieht, daß die Funktion deutlich länger ist und __udivdi3 aufruft, aus libgcc. Allerdings ist __udivdi3 nicht, wie ich zuerst vermutet hatte, eine Float-Operation, sondern eine Integer-Division. Anscheinend generiert jetzt der Compiler eine Befehlsfolge, mit der diese Division auch ohne Aufruf der Library-Funktion ausgeführt werden kann, und das Programm ist auch noch deutlich kürzer, und vermutlich unmerklich schneller.

Noch eine Anmerkung zur geänderten Datei make/Makefile.in:
Ich habe die Funktion PKG_MAKE_AC_VARIABLES_PACKAGE_SPECIFIC nicht geändert, weil meine Version nicht ganz die gleiche Funktion hätte und ich nichts durcheinander bringen wollte.
Außerdem könnte man die Idee von make/bluez-utils/bluez-utils.mk aufgreifen und $(PKG)_AC_VARIABLES, bzw. besser in der Art $(PKG)_LOCAL_CONF_VARIABLES definieren, und grundsätzlich PKG_MAKE_CONF_VARIABLES_PACKAGE_SPECIFIC aufrufen, wenn diese Variable in dem Paket gesetzt wird.

 

[olistudent]

Habs gesehen. er13 weilt derzeit leider in der Schweiz und hat keine Zeit mitzudiskutieren. Von ihm war das Macro. Aber da wir so eine Aufruf für die NOT_INCLUDED Files auch schon haben sollte das okay sein.

MfG Oliver

 

[caldir65]

Hey,

bei mir sieht's jetzt auch anders aus:

source/target-mipsel_uClibc-0.9.29/samba-3.0.37/source/lib/fsusage.o:     file format elf32-tradlittlemips

Disassembly of section .text:

00000000 <adjust_blocks>:
   0:   10a60011        beq     a1,a2,48 <adjust_blocks+0x48>
   4:   00000000        nop
   8:   00c5102b        sltu    v0,a2,a1
   c:   10400006        beqz    v0,28 <adjust_blocks+0x28>
  10:   00000000        nop
  14:   00a6001b        divu    zero,a1,a2
  18:   00c001f4        teq     a2,zero,0x7
  1c:   00001012        mflo    v0
  20:   10000009        b       48 <adjust_blocks+0x48>
  24:   70822002        mul     a0,a0,v0
  28:   00c5280a        movz    a1,a2,a1
  2c:   00c5001b        divu    zero,a2,a1
  30:   00a001f4        teq     a1,zero,0x7
  34:   24820001        addiu   v0,a0,1
  38:   00001812        mflo    v1
  3c:   0043001b        divu    zero,v0,v1
  40:   006001f4        teq     v1,zero,0x7
  44:   00002012        mflo    a0
  48:   03e00008        jr      ra
  4c:   00801021        move    v0,a0

00000050 <sys_fsusage>:
  50:   3c1c0000        lui     gp,0x0
                        50: R_MIPS_HI16 _gp_disp
  54:   279c0000        addiu   gp,gp,0
                        54: R_MIPS_LO16 _gp_disp
  58:   0399e021        addu    gp,gp,t9
  5c:   27bdff70        addiu   sp,sp,-144
  60:   afbf0088        sw      ra,136(sp)
  64:   afb30084        sw      s3,132(sp)
  68:   afb20080        sw      s2,128(sp)
  6c:   afb1007c        sw      s1,124(sp)
  70:   afb00078        sw      s0,120(sp)
  74:   afbc0010        sw      gp,16(sp)
  78:   8f990000        lw      t9,0(gp)
                        78: R_MIPS_CALL16       statfs64
  7c:   00a09821        move    s3,a1
  80:   27a50018        addiu   a1,sp,24
  84:   0320f809        jalr    t9
  88:   00c09021        move    s2,a2
  8c:   04410003        bgez    v0,9c <sys_fsusage+0x4c>
  90:   8fbc0010        lw      gp,16(sp)
  94:   10000012        b       e0 <sys_fsusage+0x90>
  98:   2402ffff        li      v0,-1
  9c:   8f820000        lw      v0,0(gp)
                        9c: R_MIPS_GOT16        .text
  a0:   8fb0001c        lw      s0,28(sp)
  a4:   24510000        addiu   s1,v0,0
                        a4: R_MIPS_LO16 .text
  a8:   8fa40028        lw      a0,40(sp)
  ac:   02002821        move    a1,s0
  b0:   0220c821        move    t9,s1
  b4:   0320f809        jalr    t9
  b8:   24060200        li      a2,512
  bc:   8fa40048        lw      a0,72(sp)
  c0:   ae420000        sw      v0,0(s2)
  c4:   02002821        move    a1,s0
  c8:   0220c821        move    t9,s1
  cc:   0320f809        jalr    t9
  d0:   24060200        li      a2,512
  d4:   8fbc0010        lw      gp,16(sp)
  d8:   ae620000        sw      v0,0(s3)
  dc:   00001021        move    v0,zero
  e0:   8fbf0088        lw      ra,136(sp)
  e4:   8fb30084        lw      s3,132(sp)
  e8:   8fb20080        lw      s2,128(sp)
  ec:   8fb1007c        lw      s1,124(sp)
  f0:   8fb00078        lw      s0,120(sp)
  f4:   03e00008        jr      ra
  f8:   27bd0090        addiu   sp,sp,144
  fc:   00000000        nop

Und das Problem mit der Meldung "disk full" ist auch beseitigt

Klasse und Danke,

Gruß, Christoph