USB-Stick an FB 7170: I/O errors + bad pages

[ao]

Hallo,

nun habe ich schon den 3. USB-Stick (Kingston) an meiner FB 7170 im Einsatz, der offenbar Probleme macht:

Buffer I/O error on device sda1, logical block 0
lost page write due to I/O error on sda1
EXT2-fs error (device sda1): ext2_readdir: bad page in #8161
Buffer I/O error on device sda1, logical block 0
lost page write due to I/O error on sda1
EXT2-fs error (device sda1): ext2_readdir: bad page in #8161
Buffer I/O error on device sda1, logical block 0
lost page write due to I/O error on sda1
EXT2-fs error (device sda1): read_inode_bitmap: Cannot read inode bitmap - block_group = 25, inode_bitmap = 819441
Buffer I/O error on device sda1, logical block 0
lost page write due to I/O error on sda1
EXT2-fs error (device sda1): ext2_get_inode: unable to read inode block - inode=2, block=242
Buffer I/O error on device sda1, logical block 0
lost page write due to I/O error on sda1
EXT2-fs error (device sda1): read_inode_bitmap: Cannot read inode bitmap - block_group = 15, inode_bitmap = 491521
Buffer I/O error on device sda1, logical block 0
lost page write due to I/O error on sda1
EXT2-fs error (device sda1): ext2_get_inode: unable to read inode block - inode=2, block=242
Buffer I/O error on device sda1, logical block 0
lost page write due to I/O error on sda1
EXT2-fs error (device sda1): ext2_readdir: bad page in #2
Buffer I/O error on device sda1, logical block 0
lost page write due to I/O error on sda1
EXT2-fs error (device sda1): ext2_readdir: bad page in #2

Habt Ihr eine Idee, woran das liegt? Muss ich in Freetz etwas anders konfigurieren?
Habe ich z.B. zu viele Pakete ausgelagert, die evtl. zu viele Schreib-Zyklen auf dem USB-Stick verursachen, der dann kaputt geht?
Oder liegt es schlicht an mangelhafter Stick-Hardware?

Danke für Euer Feedback!

Entfernt:

ASSISTANT
BRANDING_1und1
BRANDING_freenet
CHRONYD
DTRACE
HELP
MEDIASRV
MINID
SUPPORT
TR069
TR069_FWUPDATE
UPNP
USERMAN

.config:

FREETZ_HAVE_DOT_CONFIG=y
FREETZ_AVM_VERSION_04_76=y
FREETZ_TYPE_FON_WLAN_7170=y
FREETZ_AVM_VERSION_STRING="04.76"
FREETZ_TYPE_LANG_DE=y
FREETZ_TYPE_LANG_STRING="de"
FREETZ_TYPE_STRING="7170"
FREETZ_INSTALL_BASE=y
FREETZ_REPLACE_BUSYBOX=y
FREETZ_REPLACE_KERNEL_AVAILABLE=y
FREETZ_REPLACE_KERNEL=y
FREETZ_SHOW_ADVANCED=y
FREETZ_TARGET_REF="8mb_26"
FREETZ_KERNEL_REF="8mb_26"
FREETZ_KERNEL_LAYOUT="ohio"
FREETZ_KERNEL_MTD_SIZE=119
FREETZ_HAS_PHONE=y
FREETZ_HAS_TAM=y
FREETZ_HAS_WLAN=y
FREETZ_HAS_USB_HOST=y
FREETZ_HAS_LIBSSL=y
FREETZ_LANG_DE=y
FREETZ_LANG_STRING="de"
FREETZ_REMOVE_BRANDING_1und1=y
FREETZ_REMOVE_BRANDING_freenet=y
FREETZ_REMOVE_HELP=y
FREETZ_REMOVE_ASSISTANT=y
FREETZ_REMOVE_TR069=y
FREETZ_REMOVE_TR069_FWUPDATE=y
FREETZ_REMOVE_CHRONYD=y
FREETZ_PATCH_ENUM=y
FREETZ_PATCH_SIGNED=y
FREETZ_PATCH_USBSTORAGE=y
FREETZ_USBSTORAGE_AUTOMOUNT=y
FREETZ_AUTOMOUNT_EXT2=y
FREETZ_AUTOMOUNT_EXT3=y
FREETZ_AUTOMOUNT_NTFS=y
FREETZ_AUTOMOUNT_REISER_FS=y
FREETZ_AUTORUN_AUTOEND=y
FREETZ_PATCH_MAXDEVCOUNT=y
FREETZ_PATCH_MULTIPLE_PRINTERS=y
FREETZ_PATCH_GETCONS=y
FREETZ_REMOVE_SUPPORT=y
FREETZ_REMOVE_UPNP=y
FREETZ_REMOVE_USERMAN=y
FREETZ_REMOVE_MEDIASRV=y
FREETZ_REMOVE_MINID=y
FREETZ_REMOVE_DTRACE=y
FREETZ_PACKAGE_CALLMONITOR=y
FREETZ_PACKAGE_CALLMONITOR_webif=y
FREETZ_PACKAGE_CALLMONITOR_actions=y
FREETZ_PACKAGE_CALLMONITOR_monitor=y
FREETZ_PACKAGE_CALLMONITOR_phonebook=y
FREETZ_PACKAGE_DNSMASQ=y
FREETZ_PACKAGE_DROPBEAR=y
FREETZ_PACKAGE_DROPBEAR_WITH_ZLIB=y
FREETZ_PACKAGE_DROPBEAR_DISABLE_HOST_LOOKUP=y
FREETZ_PACKAGE_DTMFBOX=y
FREETZ_PACKAGE_DTMFBOX_WITH_CAPI=y
FREETZ_PACKAGE_DTMFBOX_WITH_VOIP=y
FREETZ_PACKAGE_DTMFBOX_WITH_ICE=y
FREETZ_PACKAGE_DTMFBOX_WITH_G711_CODEC=y
FREETZ_PACKAGE_DTMFBOX_SVN=y
FREETZ_PACKAGE_DTMFBOX_SVN_FORCE_LATEST_REV=y
FREETZ_PACKAGE_DTMFBOX_WITH_HELP=y
FREETZ_PACKAGE_DTMFBOX_WITH_ESPEAK=y
FREETZ_PACKAGE_DTMFBOX_WITH_MADPLAY=y
FREETZ_PACKAGE_ESPEAK=y
FREETZ_PACKAGE_NTFS=y
FREETZ_PACKAGE_OPENNTPD=y
FREETZ_PACKAGE_RRDSTATS=y
FREETZ_PACKAGE_SYSLOGD_CGI=y
FREETZ_PACKAGE_VIRTUALIP_CGI=y
FREETZ_PACKAGE_WOL_CGI=y
FREETZ_PACKAGE_DIGITEMP=y
FREETZ_PACKAGE_DIGITEMP_DS9097=y
FREETZ_PACKAGE_E2FSPROGS=y
FREETZ_PACKAGE_E2FSPROGS_E2FSCK=y
FREETZ_PACKAGE_E2FSPROGS_E2MAKING=y
FREETZ_PACKAGE_E2FSPROGS_E2TUNING=y
FREETZ_PACKAGE_FSTYP=y
FREETZ_PACKAGE_MADPLAY=y
FREETZ_PACKAGE_RRDTOOL=y
FREETZ_PACKAGE_WOL=y
FREETZ_PACKAGE_HASERL=y
FREETZ_PACKAGE_MODCGI=y
FREETZ_DL_SITE="[URL]ftp://ftp.avm.de/fritz.box/fritzbox.fon_wlan_7170/firmware/deutsch[/URL]"
FREETZ_DL_SOURCE="FRITZ.Box_Fon_WLAN_7170.29.04.76.image"
FREETZ_MOD_DL_NUM_SITES="5"
FREETZ_MOD_DL_SITE_1="[URL]http://freetz.3dfxatwork.de[/URL]"
FREETZ_MOD_DL_SITE_2="[URL]http://freetz.wirsind.info[/URL]"
FREETZ_MOD_DL_SITE_3="[URL]http://freetz.magenbrot.net[/URL]"
FREETZ_MOD_DL_SITE_4=""
FREETZ_MOD_DL_SITE_5=""
FREETZ_SECURITY_LEVEL=0
FREETZ_VERBOSITY_LEVEL=2
FREETZ_FAVICON_DSL123=y
FREETZ_FAVICON_STRING="dsl123"
FREETZ_SUBVERSION_STRING=y
FREETZ_DEVELOPER_VERSION_STRING=y
FREETZ_STATUS_STYLE=y
FREETZ_USER_DEFINED_COMMENT=""
EXTERNAL_ENABLED=y
EXTERNAL_SUBDIRS=y
EXTERNAL_CREATEPAK=y
EXTERNAL_DIR1=y
EXTERNAL_DIRECTORY="/var/media/ftp/uStor01/external/"
EXTERNAL_OWN_FILES=""
EXTERNAL_FREETZ_PACKAGE_E2FSPROGS=y
EXTERNAL_FREETZ_PACKAGE_E2FSPROGS_e2fsck=y
EXTERNAL_FREETZ_PACKAGE_E2FSPROGS_mke2fs=y
EXTERNAL_FREETZ_PACKAGE_E2FSPROGS_mklost_found=y
EXTERNAL_FREETZ_PACKAGE_E2FSPROGS_tune2fs=y
EXTERNAL_FREETZ_PACKAGE_E2FSPROGS_dumpe2fs=y
EXTERNAL_FREETZ_PACKAGE_E2FSPROGS_chattr=y
EXTERNAL_FREETZ_PACKAGE_E2FSPROGS_lsattr=y
EXTERNAL_FREETZ_PACKAGE_ESPEAK=y
EXTERNAL_FREETZ_PACKAGE_DIGITEMP=y
EXTERNAL_FREETZ_PACKAGE_DTMFBOX=y
EXTERNAL_FREETZ_PACKAGE_MADPLAY=y
EXTERNAL_FREETZ_PACKAGE_NTFS=y
EXTERNAL_FREETZ_PACKAGE_RRDTOOL=y
EXTERNAL_FREETZ_LIB_libart_lgpl_2=y
EXTERNAL_FREETZ_LIB_libfreetype=y
EXTERNAL_FREETZ_LIB_libid3tag=y
EXTERNAL_FREETZ_LIB_libmad=y
EXTERNAL_FREETZ_LIB_libpng12=y
FREETZ_SQUASHFS_BLOCKSIZE_131072=y
FREETZ_BUSYBOX_START_STOP_DAEMON=y
FREETZ_BUSYBOX_WGET=y
FREETZ_BUSYBOX_NICE=y
FREETZ_MODULE_usbserial=y
FREETZ_MODULE_pl2303=y
FREETZ_MODULE_ftdi_sio=y
FREETZ_MODULE_ext3=y
FREETZ_MODULE_ext2=y
FREETZ_MODULE_hfs=y
FREETZ_MODULE_hfsplus=y
FREETZ_MODULE_fuse=y
FREETZ_MODULE_jbd=y
FREETZ_MODULE_nls_utf8=y
FREETZ_MODULE_reiserfs=y
FREETZ_MODULE_mbcache=y
FREETZ_LIB_libz=y
FREETZ_LIB_libfreetype=y
FREETZ_LIB_libart_lgpl_2=y
FREETZ_LIB_libpng12=y
FREETZ_LIB_ld_uClibc=y
FREETZ_LIB_libcrypt=y
FREETZ_LIB_libdl=y
FREETZ_LIB_libm=y
FREETZ_LIB_libnsl=y
FREETZ_LIB_libpthread=y
FREETZ_LIB_librt=y
FREETZ_LIB_libuClibc=y
FREETZ_LIB_libutil=y
FREETZ_LIB_libuClibc__=y
FREETZ_LIB_libgcc_s=y
FREETZ_LIB_libcapi20=y
FREETZ_LIB_libid3tag=y
FREETZ_LIB_libmad=y
FREETZ_LIB_libfreetz=y
FREETZ_DOWNLOAD_TOOLCHAIN=y
FREETZ_TARGET_CROSS="mipsel-linux-uclibc-"
FREETZ_TARGET_MAKE_PATH="toolchain/target/bin"
FREETZ_TARGET_CFLAGS="-Os -pipe -march=4kc -Wa,--trap"
FREETZ_JLEVEL=2
FREETZ_KERNEL_CROSS="mipsel-unknown-linux-gnu-"
FREETZ_KERNEL_MAKE_PATH="toolchain/kernel/bin"
FREETZ_KERNEL_VERSION_2_6_13_1=y
FREETZ_KERNEL_VERSION="2.6.13.1"
FREETZ_TARGET_UCLIBC_VERSION_0_9_29=y
FREETZ_TARGET_COMPILER_GCC_4_2_4_UCLIBC_0_9_29=y
FREETZ_TARGET_GCC_VERSION="4.2.4"
FREETZ_TARGET_UCLIBC_VERSION="0.9.29"
FREETZ_TARGET_BINUTILS_VERSION="2.18"
FREETZ_TARGET_UCLIBC_REF="mod"
FREETZ_TARGET_GXX=y
FREETZ_TARGET_CCACHE=y
FREETZ_TARGET_LFS=y
FREETZ_KERNEL_GCC_VERSION="3.4.6"
FREETZ_KERNEL_BINUTILS_VERSION="2.17.50.0.17"

Ausgelagerte Dateien:

lib/libid3tag.so.0.3.0
lib/libmad.so.0.2.1
usr/lib/libfreetype.so.6.3.16
usr/lib/libpng12.so.0.10.0
usr/lib/libart_lgpl_2.so.2.3.19
usr/lib/librrd.so.2.0.15
usr/bin/ntfs-3g
usr/bin/speak
usr/bin/madplay
usr/bin/digitemp
usr/bin/rrdtool
usr/sbin/tune2fs
usr/sbin/mklost+found
usr/sbin/mke2fs
usr/sbin/chattr
usr/sbin/lsattr
usr/sbin/dumpe2fs
usr/sbin/e2fsck
usr/sbin/dtmfbox

 

[olistudent]

Hi.

Wann treten die Fehler denn auf?

Ich wüßte nicht was wir da in Freetz konfigurieren sollten...

MfG Oliver

 

[hermann72pb]

@ao: Checke doch deine Sticks mit e2fsck. Du kannst das Tool sogar auf die Box mitnehmen. Es gibt mittlerweile auch das Gegenstück für dos im trunk: dosfsprogs. Ich gehe eher davon aus, dass dein Dateisystem zerschossen ist und nicht, dass die Sticks physikalisch kaputt sind.
Sowas passiert oft, wenn du zu viel auf den Stick schreibst. Z.B. diverse Logs, config-Dateien von diversen Paketen, etc. Wenn deine Box mitten im Schreibzugriff rebootet, dann hast du ein Problem. Schlimm an der Sache ist, dass du zeitlang davon gar nichts mitbekommst. Und wenn die Auswirkungen sich bemerkbar machen, ist dein Dateisystem schon ordentlich zerschossen. Das hatte ich bei mir schon einmal erlebt. Deswegen hatte ich mich an dosfsprogs dran gemacht. Ziel wäre es, eine Automatische Prüfung der Medien per cron einzuführen und im Fehlerfall den Benutzer zu informieren. Interessanterweise erlauben sowohl e2fsck, als auch dos-checker auch eingebundene Partitionen im Lesemodus (ohne Korrektur) zu checken. Dies könnte man als erstes tun und erst im Fehlerfall die Partition unmounten und richtig reparieren.

MfG

 

[ao]

[...]Schlimm an der Sache ist, dass du zeitlang davon gar nichts mitbekommst. [...]
Ziel wäre es, eine Automatische Prüfung der Medien per cron einzuführen und im Fehlerfall den Benutzer zu informieren.

Das ist eine prima Idee, denn in der Tat hatte ich das Problem erst bemerkt, als rrdstats/ digitemp nicht mehr richtig liefen.
Ich werde mal checken, was da nun wirklich los ist.

 

[Silent-Tears]

Eher sinnig ist übrigens die Stelle, an der gemountet wird, und dort dsirekt einen fsck durchzuführen. Aber das rauszufinden ist gar nicht so einfach, glaube ich.
@herman: du bist doch da grad dran am basteln. interesse dort noch mehr einzubauen, wenn AVM das schon nicht selber hinbekommt?

 

[hermann72pb]

@Silent-Tears: Genau deswegen hatte ich es ausgelagert. Jetzt liegen diese mount-Sachen in "unserer" libmodmount.sh-Datei und können nachher beliebig erweitert werden. Man kann da sicherlich eine Möglichkeit einführen, die Partitionen vor dem mount zu checken. Allerdings wird sowas relativ langsam ablaufen. Der Benutzer wird dadurch irritiert, weil er nichts mitkriegt, was da genau abläuft. Dies wäre der klassische Linux-Weg mit dem Unterschied, das wir noch keinen Bildschirm an der Box haben.
Deswegen wäre es viel interessanter so zu machen, wie ich vorher vorgeschlagen hatte: Passiv per cron testen und im Ernstfall die Box rebooten und dann reparieren. Aber dafür sollte man schon ein extra-Paket entwerfen. Ich will es nicht mehr so global unter mod packen, wie diese automount-Geschichte.

MfG

 

[ao]

Kann man die Info-LED dazu verwenden, einen laufenden fsck zu signalisieren?
Mir würde es zwar nichts bringen (FB steht im Netzwerkschrank im Keller), aber zumindest denjenigen, die sie "in der Nähe" haben.

 

[hermann72pb]

Nein, würde ich nicht machen. Die ist doch schon von AVM für alles Mögliche reserviert. Die Box läuft doch rund um die Uhr. Was spricht dagegen die Prüfung auf eine Zeit zu legen, wo keiner die Box braucht? Entweder tagsüber oder nachts. Dann könnte man den check laufen lassen.
Ich hatte gestern bereits mit diesem und jenem gespielt und weiß mittlerweile halbwegs, wie AVM die Sticks einbindet und wie sie die abtrennt. Mann sollte da anstatt unmount den AVMs "storage unplug" nehmen und zurück-"mount" evtl. mittles "storage add" realisieren, wobei "add" leider alle Partitionen auf einmal einbindet. Hier wäre schon kein Problem (auch nicht mit der TAM-Partition) gegeben.
Vielmehr Sorgen machen mir allerdings passive checks, die ich gestern auf gemounteden Partitionen durchgeführt hatte. Es wird da zwar eine Menge von Infos ausgespuckt (vor allem in Verbose mode), aber ob man die vernünftig mit sed/grep filtern kann, um die Entscheidung über Reparatur zu treffen, das mag ich zu bezweifeln. Jedoch jedesmal eine "scharfe" Prüfung inklusive Reparatur zu machen finde ich ebenfalls für übertrieben.

MfG

 

[RalfFriedl]

Der Check kann nicht laufen, während das Dateisystem verwendet wird. Normalerweise wird er vor dem Mounten ausgeführt.

 

[ao]

Ok, das mit der LED ist dann wohl nicht so sinnvoll.
Aber wäre es sinnvoll/möglich, sich den Status per Pushservice zukommen zu lassen?
Dann könnte man anhand des Outputs selbst entscheiden, ob eine (halb-)automatische Prüfung ohne (optional mit) Fehlerkorrektur anlaufen soll - falls die Auswertung mittels sed/grep zu schwierig werden sollte.
Parallel zum Pushservice könnte eine Status-Anzeige auf der Startseite des Freetz-WebGUIs stehen, wo man ja ab und zu auch reinschaut.

 

[hermann72pb]

@ao: In die Richtung kann man gehen. An so etwas hatte ich auch gedacht.
@RalfFriedl: Probier es doch aus. Die e2fsck und dosfsck, die wir auf der Box haben (optional, natürlich) weigern sich tatsächlich im Normalfall:

/var/mod/root # e2fsck /dev/sda1
e2fsck 1.41.9 (22-Aug-2009)
/dev/sda1 is mounted.

WARNING!!!  Running e2fsck on a mounted filesystem may cause
SEVERE filesystem damage.

Do you really want to continue (y/n)? no

check aborted.

Wenn du aber etwas nachhilfst und mit "-n" startest, dann klappt es:

/var/mod/root # e2fsck -n /dev/sda1
e2fsck 1.41.9 (22-Aug-2009)
Warning!  /dev/sda1 is mounted.
SYSTEM was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
SYSTEM: 3195/147456 files (0.0% non-contiguous), 32762/265064 blocks
/var/mod/root # echo $?
0
/var/mod/root # dosfsck -n /dev/sda2
dosfsck 3.0.5, 27 Jul 2009, FAT32, LFN
Reclaimed 3 unused clusters (12288 bytes).
Free cluster summary wrong (461341 vs. really 461344)
  Auto-correcting.
Leaving file system unchanged.
/dev/sda2: 115 files, 67763/529107 clusters
/var/mod/root # echo $?
1
/var/mod/root # e2fsck -n /dev/sda5
e2fsck 1.41.9 (22-Aug-2009)
Warning!  /dev/sda5 is mounted.
DATA was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
DATA: 11/278528 files (0.0% non-contiguous), 8752/534153 blocks
/var/mod/root # echo $?
0
/var/mod/root # e2fsck -n /dev/sda6
e2fsck 1.41.9 (22-Aug-2009)
Warning!  /dev/sda6 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
ARCHIV has been mounted 53 times without being checked, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
ARCHIV: 11/311296 files (9.1% non-contiguous), 17981/610462 blocks
/var/mod/root # echo $?
0

Jetzt würde ich es anhand $? so frei interpretieren, dass meine EXT2 an sda1 und sda5, EXT3 an sda6 sauber sind und FAT an sda2 dagegen nicht.
Die Fehlercodes sind übrigens interessant. Sowas wird im Falle einer logischen Partition sda3 ausgespuckt:

/var/mod/root # e2fsck -n /dev/sda3
e2fsck 1.41.9 (22-Aug-2009)
e2fsck: Attempt to read block from filesystem resulted in short read while trying to open /dev/sda3
Could this be a zero-length partition?
/var/mod/root # echo $?
8
/var/mod/root # dosfsck -n /dev/sda3
dosfsck 3.0.5, 27 Jul 2009, FAT32, LFN
Logical sector size is zero.
/var/mod/root # echo $?
1

Und sowas bei SWAP sda4:

/var/mod/root # e2fsck -n /dev/sda4
e2fsck 1.41.9 (22-Aug-2009)
Warning!  /dev/sda4 is mounted.
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/sda4

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

/var/mod/root # echo $?
8
/var/mod/root # dosfsck -n /dev/sda4
dosfsck 3.0.5, 27 Jul 2009, FAT32, LFN
Logical sector size is zero.
/var/mod/root # echo $?
1

e2fsck scheint da die Fehler vernünftiger zu bearbeiten.
Eigentlich bräuchten wir langsam einen fsck-Wrapper. Gibt es da was fertiges oder soll ich das Rad selbst erfinden? Es ging mir darum, dass man freizügig

fsck /dev/sdXX

angeben könnte, und er würde sich automatisch den passenden fsck.ext2, fsck.fat oder was auch immer suchen. Die Letzten sind nur symlinks, es geht eher um die automatische Erkennung.

MfG

 

[RalfFriedl]

Wenn du aber etwas nachhilfst und mit "-n" startest, dann klappt es:

Es kann dann aber sein, daß Du Inkonsistenzen gemeldet bekommst, einfach nur weil Daten aus dem Cache noch nicht auf die Platte geschrieben worden sind.

 

[hermann72pb]

Naja, ist es denn so schlimm? Wie oft würde sowas passieren? Dann wird in meinem Fall einen Fehler gemeldet, der in Wirklichkeit nicht existiert.
Hatte übrigens eben meine FAT-Partition erfolgreich repariert. Mit /etc/hotplug/storage erfolgreich runtergefahren, gecheckt und wieder hoch gefahren. Es würde sich also schon automatisieren lassen. Ich würde es echt so vorschlagen zu machen, dass man die Tests dann durchführt, wenn auf den Medien am Wenigsten was los ist. Schlagen die Tests fehl, dann wird das Medium unmounted, repariert und wieder eingebunden. Man sollte es allerdings schon konfigurierbar machen, dass man gewisse Partitionen von der Prüfung ausschließen könnte.
Meine (für FREETZ) neue Methode nach dem LABEL zu mounten könnte hierbei zusätzlich behilflich sein. Die Reaktion auf meine Methode hält sich allerdings in Grenzen, wenn ich mir die 2 Downloads ansehe. Oder hat keiner verstanden, was damit überhaupt möglich ist?

MfG

 

[RalfFriedl]

Ob es schlimm ist, ist Ansichtssache. Wie oft es passiert hängt davon ab, wie häufig auf der Partition etwas geändert wird. Unmounten geht nur, wenn keine einzige Datei mehr auf der Partition offen ist. Normalerweise sollte eine konsistente Partition nicht im Betrieb inkonsistent werden.

 

[hermann72pb]

Ralf, du hast vollkommend Recht, wenn du die Sache, aus der Sicht vom normalen Benutzer von Linux-PC betrachtest. Ich schlage lediglich vor, das wir uns von diesen typischen Dogmen eben ablösen und etwas komplett anderes machen, obwohl meine Vorschläge für deine erfahrenen Augen vielleicht erstmal verrückt und völlig abnormal klingen. Wir haben leider keinen Monitor, das ist Fakt. Wir können dem Benutzer nicht zumuten, dass er 5 Minuten ahnungslos wartet, bis seine Telefonanlage überhaupt los fährt. Und ich behaupte mal, dass bei 98% der Benutzer hier eine Zeitspanne von 1 Stunde irgendwo finden lassen würde, in der man die Platte/ den Stick in Ruhe testen könnte und beim Bedarf reparieren.
Du sagst, die Partition darf normalerweise nicht inkonsistent werden. Gebe ich dir auch vollkommend Recht, dass es so theoretisch sein sollte. Die Praxis zeigt uns aber leider ein völlig anderes Bild, in dem die zerschossenen Stick-partitionen deutlich öfter auftauchen, als man es haben wollte.
Aus diesen Gründen würde ich rein progmatisch genau so vorgehen, wie ich vorgeschlagen hatte, ob es letztendlich sinnig ist oder nicht, kann man ja später sehen.

MfG

 

[ao]

Hallo, noch eine kleine Anmerkung:
Das Unmounten, Checken/Reparieren und Mounten sollte m.E. nicht die Grundfunktion der FB stören, d.h. das Telefonieren und damit verbundene Freetz-Pakete, oder?
D.h. gibt es eine Möglichkeit, schon beim FW-Bau (make menuconfig) darauf hinzuweisen, welche Pakete man evtl. nicht externalisierten sollte, wenn man unbedingt immer Telefonieren können will?
Falls gar keine Freetz-Pakete betroffen sind, hat sich meine Frage erledigt, aber spontan fällt mir da schon einmal dtmfbox ein, sofern man CallThrough u.ä. daraus verwendet.

 

[hermann72pb]

@ao: Wenn du um 3 Uhr nachst unbedingt telefonieren willst, dann wird es dich stören. Ich will damit sagen, dass man es natürlich unendlich weit und hoch treiben kann und irgendwelche Abhängigkeiten und Warnungen in menuconfig einbauen, aber letztendlich ist es jedem selbst überlassen, wie und wann er seine Medien kontrolliert. Etwas Intelligenz sollte man vom Benutzer schon verlangen. Wir sind hier schließlich nicht im Kindergarten oder nicht bei AVM. Wer FREETZ benutzt, muss selbst wissen, was er tut.

MfG

 

[ao]

Kindergarten? Ich hatte gefragt, ob man dem FW-Bastler mitteilen könnte, welche Module bzw. Pakete von Freetz zum Telefonieren nötig sind.
Da muss man doch nicht gleich so pauschal abwatschen, oder?

 

[hermann72pb]

@ao: Ich halte den Aufwand dies zu realisieren für zu hoch gegenüber dem, dass man von demjenigen, der solche check-Routinen verwendet eine gewisse Intelligenz fordert. dtmfbox ist nur ein Beispiel. Wenn man da noch external Sachen pauschal dazu packt und vielleicht noch USB-Root-Partition, dann wird es zu viel. Wie sollen deiner Meinung nach die Suchkriterien auf der Box aussehen, damit ich vor dem Check weiß, ob du dtmfbox hast oder nicht, oder ob eine oder andere Binary bei dir nicht ausgelagert ist? Vor allem, wo dann die kritischen Sachen liegen wird es nicht einfach automatisch zu ermitteln.
Die Schutzmaßnahmen dagegen wären die Optionalität der Prüfung, die vom Benutzer manuell festzulegen wäre und Verzicht auf "force"-Optionen beim unmount/check.

MfG

 

[ao]

Sorry, Herrmann, ich glaube, wir schreiben aneinander vorbei. ;-)
Ich meine, dass es evtl. ausreicht, einfach im "make menuconfig" diejenigen Freetz-Pakete mit einem entsprechenden Hinweis zu versehen, die etwas mit Telefonie zu tun haben, da ich mir vorstellen kann, dass das nicht bei allen gleich ersichtlich ist. Oder meintest Du genau das mit den Abhängigkeiten? Dann wäre es doch nicht "aneinander vorbei". Wie auch immer: Ich fände so einen Hinweis vor dem FW-Bau sinnvoll, weil der Nutzer dann entscheiden kann, welche Pakete er externalisieren will und welche besser nicht (wenn Platz ist; ggf. geht ja auch DL). Denn ein sowohl ein verkorkster USB-Stick als auch einer, bei dem gerade fsck o.ä. läuft, würde ja die Nutzung der externalisierten Pakete verhindern, oder nicht?
Wie läuft denn übrigens die Box mit Freetz aber ohne USB-Stick, wenn dort Pakete externalisiert sind? Lassen sich für einen USB-Stick-Check Dienste etc., die auf externalisierte Daten angewiesen sind, vorübergehend stoppen und dann wieder automatisch starten, oder ist das gar kein Problem?