kernel: name_count maxed, losing inode data: dev=00:05...

Welches Modul/Treiber für welche Hardware, Kernel compilieren...
Antworten
WEARENOTALONE
Beiträge: 278
Registriert: 19.04.2009 18:55:05

kernel: name_count maxed, losing inode data: dev=00:05...

Beitrag von WEARENOTALONE » 24.11.2009 09:45:10

Hallo zusammen,
heute morgen ist mir aufgefallen, dass mein Kernel 2.6.26 (System ist eigentlich Debian Squeeze) folgende Meldungen ausgibt:

Code: Alles auswählen

...
Nov 24 08:56:04 HOSTNAME kernel: [   31.392346] EXT3 FS on dm-2, internal journal
Nov 24 08:56:04 HOSTNAME kernel: [   37.237676] name_count maxed, losing inode data: dev=00:05, inode=6
Nov 24 08:56:04 HOSTNAME kernel: [   37.237680] name_count maxed, losing inode data: dev=00:05, inode=6158
Nov 24 08:56:04 HOSTNAME kernel: [   37.237706] name_count maxed, losing inode data: dev=00:05, inode=6
Nov 24 08:56:04 HOSTNAME kernel: [   37.237709] name_count maxed, losing inode data: dev=00:05, inode=6160
Nov 24 08:56:04 HOSTNAME kernel: [   37.237738] name_count maxed, losing inode data: dev=00:05, inode=6
Nov 24 08:56:04 HOSTNAME kernel: [   37.237749] name_count maxed, losing inode data: dev=00:05, inode=6162
...
Die Meldung kommt kurz nachdem mein root Dateisystem eingehängt und noch bevor die restlichen Dateisysteme (alle ext3) eingehängt werden. Ich vermute daher, die Meldungen beziehen sich auf das Device dm-2 auf dem mein root Dateisystem liegt [ LVM2 Volume ("dm-2") => MD Raid 0 => 2x SATA Festplatten ]. Meine Logfiles sagen mir, dass diese Meldung außerdem am 17. und 22. November ausgegeben wurden. Laut diesem Bugreport von Fedora hat es wohl irgendwas mit dem System-call auditing support zu tun, aber leider hilft mir das nicht weiter. Eine wilde Spekulation von mir ist, dass es eventuell mit dem Paket readahead-fedora zu tun hat, welches ebenfalls mit dem auditing subsystem zu tun hat.

Muss ich mir Sorgen um meine Daten machen?

Mit freundlichen Grüßen
WANA

Benutzeravatar
SubOptimal
Beiträge: 1709
Registriert: 10.01.2005 23:25:46
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: bei Frankfurt

Re: kernel: name_count maxed, losing inode data: dev=00:05...

Beitrag von SubOptimal » 24.11.2009 12:51:46

Hi,
WEARENOTALONE hat geschrieben:Ich vermute daher, die Meldungen beziehen sich auf das Device dm-2 auf dem mein root Dateisystem liegt
Ein

Code: Alles auswählen

lsof | grep 0,5
gibt Dir Auskunft welche Dateien auf dem Device dev=00:05 geöffnet sind.

Für ein ext2/ext3/ext4 Dateisystem kannst Du wie folgt heraus bekommen welche Datei einen Inode belegt.

Beispiel für inode=6158 und angenommen /dev/mapper/lvm-home ist gemountet als /home

Code: Alles auswählen

echo ncheck 6158 | debugfs /dev/mapper/lvm-home
SubOptimal

WEARENOTALONE
Beiträge: 278
Registriert: 19.04.2009 18:55:05

Re: kernel: name_count maxed, losing inode data: dev=00:05...

Beitrag von WEARENOTALONE » 24.11.2009 13:51:38

Vielen Dank für die Informationen!

Allerdings sind auf dem device 00:05 keine Dateien geöffnet, die Ausgabe von lsof ist leer. Der debugfs Befehl, angewendet auf mein Rootverzeichnis gibt bei keiner der oben angegebenen inodes eine Ausgabe. Wie finde ich heraus, was denn dieses device 00:05 ist? Wird beim Laden der initrd nicht auch ein temporäres Dateisystem gemountet, kann es sich vllt. darum handeln?

EDIT1: dmesg | grep 00:05 gibt ebenfalls keine Ausgabe.

Benutzeravatar
SubOptimal
Beiträge: 1709
Registriert: 10.01.2005 23:25:46
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: bei Frankfurt

Re: kernel: name_count maxed, losing inode data: dev=00:05...

Beitrag von SubOptimal » 26.11.2009 15:36:14

Wie finde ich heraus, was denn dieses device 00:05 ist? Wird beim Laden der initrd nicht auch ein temporäres Dateisystem gemountet, kann es sich vllt. darum handeln?
Da muss ich jetzt auch erstmal passen.
Der debugfs Befehl, angewendet auf mein Rootverzeichnis gibt bei keiner der oben angegebenen inodes eine Ausgabe
Und wenn er was gefunden hätte, dann wäre es in dem Fall auch nicht richtig gewesen.
Die Ausgaben von debugfs stehen immer in Relation zum untersuchten Filesystem. Wenn man wissen will von welcher Datei der inode 12345 auf FilesystemA belegt wird. Zu wissen, dass der inode 12345 auf FilesystemB von DateiC belegt ist, hilft einem da nicht weiter. Oder? ;-)

SubOptimal

edit: Das "dev=00:05" könnte mit SELinux zusammenhängen http://www.nsa.gov/research/selinux/lis ... dy30.shtml.

Benutzeravatar
KBDCALLS
Moderator
Beiträge: 22447
Registriert: 24.12.2003 21:26:55
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Dortmund
Kontaktdaten:

Re: kernel: name_count maxed, losing inode data: dev=00:05...

Beitrag von KBDCALLS » 26.11.2009 18:58:06

Über diese Fehlermeldung ist relativ wenig zu finden. Es tauchte auch im Zusammenhang mit dem Laden von Firmware auf.

http://www.mail-archive.com/bcm43xx-dev ... 09136.html

Hiernach ist dev=00:05 das Pipefs Also nix was irgeneine Partiton betriftt.

Code: Alles auswählen

SELinux: initialized (dev 00:05, type pipefs), uses task SIDs
SELinux: initialized (dev 00:04, type tmpfs), uses transition SIDs
SELinux: initialized (dev 00:03, type sockfs), uses task SIDs
SELinux: initialized (dev 00:02, type proc), uses genfs_contexts
SELinux: initialized (dev 00:01, type bdev), not configured for labeling
SELinux: initialized (dev 00:00, type rootfs), not configured for
Das schreibt übrigens Die devices.txt der Kerneldocu dazu
devices.txt hat geschrieben:

Code: Alles auswählen

  0             Unnamed devices (e.g. non-device mounts)
                  0 = reserved as null device number
                See block major 144, 145, 146 for expansion areas.
...
144 block       Expansion Area #1 for more non-device (e.g. NFS) mounts
                  0 = mounted device 256
                255 = mounted device 511

Was haben Windows und ein Uboot gemeinsam?
Kaum macht man ein Fenster auf, gehen die Probleme los.

EDV ist die Abkürzung für: Ende der Vernunft

Bevor du einen Beitrag postest:
  • Kennst du unsere Verhaltensregeln
  • Lange Codezeilen/Logs gehören nach NoPaste, in Deinen Beitrag dann der passende Link dazu.

WEARENOTALONE
Beiträge: 278
Registriert: 19.04.2009 18:55:05

Re: kernel: name_count maxed, losing inode data: dev=00:05...

Beitrag von WEARENOTALONE » 04.12.2009 14:11:14

Hallo zusammen,
vielen Dank für eure Antworten! Das Problem tritt seltsamerweise auch nur alle 1 bis 4 Tage auf. Aber wenn es sich nicht um meine Partitionen/Daten handelt, werde ich die Meldung erstmal ignorieren.

Viele Grüße
WANA

Antworten