Hi, There!
On a newly installed 2.6.14.2 (vanilla), when I do a
root@testserver: /$ find | grep something.conf
I get
.....
find: WARNING: Hard link count is wrong for .: this may be a bug in your filesystem driver. Automatically turning on find's -noleaf option. Earlier results may have failed to include directories that should have been searched.
According to google, this might be a kernel bug due to some problems in /proc, see:
https://www.redhat.com/archives/fedora-list/2005-September/msg02474.html
Well, how to debug that problem?
Greets,
--
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
Clemens Koller wrote:
> I get
>
> .....
> find: WARNING: Hard link count is wrong for .: this may be a bug in your
> filesystem driver. Automatically turning on find's -noleaf option.
> Earlier results may have failed to include directories that should have
> been searched.
>
> According to google, this might be a kernel bug due to some problems in
> /proc, see:
> https://www.redhat.com/archives/fedora-list/2005-September/msg02474.html
> Well, how to debug that problem?
That find check is somewhat incorrect (hard link count can be legally modified
after the search was started and before it finished), but I did fix up the
/proc problems that existed a while back.
This patch will give you a more useful error from findutils.
Daniel
On Saturday 19 November 2005 3:08 am, you wrote:
> > find: WARNING: Hard link count is wrong for .: this may be a bug in your
> > filesystem driver. Automatically turning on find's -noleaf option.
> > Earlier results may have failed to include directories that should have
> > been searched.
> >
> > According to google, this might be a kernel bug due to some problems in
> > /proc, see:
> > https://www.redhat.com/archives/fedora-list/2005-September/msg02474.html
> > Well, how to debug that problem?
>
> That find check is somewhat incorrect (hard link count can be legally
> modified after the search was started and before it finished), but I did
> fix up the /proc problems that existed a while back.
>
> This patch will give you a more useful error from findutils.
I just had the same problem (first time ever) with 2.6.14.2.
The patched find says:
find: WARNING: Hard link count (5) is wrong for /proc/bus: this may be a bug
in your filesystem driver. Automatically turning on find's -noleaf option.
Earlier results may have failed to include directories that should have been
searched.
My /proc/bus/ contains this:
# ls -al /proc/bus/
total 0
dr-xr-xr-x 5 root root 0 Nov 18 01:45 ./
dr-xr-xr-x 199 root root 0 Nov 18 02:45 ../
dr-xr-xr-x 2 root root 0 Nov 20 15:16 input/
dr-xr-xr-x 2 root root 0 Nov 20 15:16 pccard/
dr-xr-xr-x 5 root root 0 Nov 20 10:45 pci/
drwxr-xr-x 6 root root 0 Nov 18 01:45 usb/
I checked on a few machines I have with the same kernel version, but this
happens only on my notebook. Is there any other test I can do to help
pinpoint the problem?
--
Bye,
Massimiliano Hofer
On Sunday 20 November 2005 4:07 pm, you wrote:
> It's not obvious why that is the case. Could you try building usb and
> pcmcia as non-autoloaded modules, and booting up without those loaded to
> see if its correct at with just pci and input? (hard link count should be 4
> at that point).
>
> You could then try loading usb/pccard while keeping an eye on the hard link
> count, see if you can get a clearer idea of where the problem is.
>
> Thanks,
> Daniel
Your suspects about pccard are right:
# find /proc/ >/dev/null
/tmp/findutils-4.2.23-5/findutils-4.2.23/find/find: WARNING: Hard link count
(5) is wrong for /proc/bus: this may be a bug in your filesystem driver.
Automatically turning on find's -noleaf option. Earlier results may have
failed to include directories that should have been searched.
# rmmod pcmcia
# find /proc/ >/dev/null
# modprobe pcmcia
# find /proc/ >/dev/null
/tmp/findutils-4.2.23-5/findutils-4.2.23/find/find: WARNING: Hard link count
(5) is wrong for /proc/bus: this may be a bug in your filesystem driver.
Automatically turning on find's -noleaf option. Earlier results may have
failed to include directories that should have been searched.
I'll write back as soon as possible with more tests.
--
Bye,
Massimiliano Hofer
On Sunday 20 November 2005 4:14 pm, Massimiliano Hofer wrote:
> I'll write back as soon as possible with more tests.
I'm back. First of all I beg your pardon for blaming 2.6.14.2, I forgot I
rebooted with 2.6.13.4.
A cursory check of the mailing list and the changelog doesn't show any obvious
change in 2.6.14 that would solve this, but I may be overlooking something.
Anyway I couldn't reproduce the bug in 2.6.14.2, but it is easily reproducible
with 2.6.13.4. Adding and removing a 8139too PCMCIA card I managed to get this
warning:
find: WARNING: Hard link count (5) is wrong for /proc/bus/pci: this may be a
bug in your filesystem driver. Automatically turning on find's -noleaf
option. Earlier results may have failed to include directories that should
have been searched.
Compiling pcmcia in the kernel (but leaving yenta and 8139too as a module) I
never get errors on /proc/bus, but I get the same results on /proc/bus/pci.
It seems a broader hotplug problem. Of corse it could be already solved in
2.6.14, as I can't reproduce it.
--
Bye,
Massimiliano Hofer
--- findutils-4.2.26/find/find.c~ 2005-11-11 08:41:37.000000000 +0100
+++ findutils-4.2.26/find/find.c 2005-11-21 11:47:35.000000000 +0100
@@ -1947,8 +1947,8 @@ process_dir (char *pathname, char *name,
* doesn't really handle hard links with Unix semantics.
* In the latter case, -noleaf should be used routinely.
*/
- error(0, 0, _("WARNING: Hard link count is wrong for %s: this may be a bug in your filesystem driver. Automatically turning on find's -noleaf option. Earlier results may have failed to include directories that should have been searched."),
- parent);
+ error(0, 0, _("WARNING: Hard link count (%d) is wrong for %s: this may be a bug in your filesystem driver. Automatically turning on find's -noleaf option. Earlier results may have failed to include directories that should have been searched."),
+ statp->st_nlink, pathname);
state.exit_status = 1; /* We know the result is wrong, now */
options.no_leaf_check = true; /* Don't make same
mistake again */