[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fwd: find -noleaf

From: James Youngman
Subject: Fwd: find -noleaf
Date: Tue, 8 May 2007 16:50:41 +0100

Contrary to what I wrote below, I had not copied this to the list.
I'm now doing so.    Did you get a chance to retest your problem with
a modern version of findutils?

---------- Forwarded message ----------
From: James Youngman <address@hidden>
Date: May 4, 2007 11:26 PM
Subject: Re: find -noleaf
To: Gregg Tracton <address@hidden>

On 5/4/07, Gregg Tracton <address@hidden> wrote:

Hi, I am copying this email to the mailing list.  I hope you don't mind.

We have multiple deadlines for paper so I've been delaying answering
your questions.
Thanks for getting back to me and being so patient.

Here's a little experiment that may suggest that when the filesystem is
"UNKNOWN" then 'find' should disable leaf optimization,

I underatand your point.  Unfortunately, find tries to defer figuring
out filesystem types.  On many platforms it needs to stat all the
entries in /etc/fstab to do this, and if the system is a client of any
unresponsive NFS server, this can cause find to hang (specifically,
get stuck in the 'D' state).

in addition to testing st_nlinks < 2.  On an AFS disk:

Aha, AFS!   Did you compile using the --with-afs option to configure?
Did it work?   You might also want to read an earlier thread on this:

My ability to test things with AFS is pretty much nonexistent.  Even
if I could build a system with AFS support, there are few AFS cells
offering write access to unidentified users, I'd guess.

address@hidden 177: mkdir theDir
address@hidden 178: touch theDir/theFile
address@hidden 179: find .

--> OK, so that's the symptom: 'find' does not print a line for

address@hidden 183: find -noleaf

--> Good: -noleaf works as advertised

address@hidden 186: stat -f theDir
  File: "theDir"
    ID: 6300001234 Namelen: 256     Type: UNKNOWN (0x0)
Blocks: Total: 9000000    Free: 9000000    Available: 9000000    Size: 1024
Inodes: Total: 9000000    Free: 9000000

Oops, UNKNOWN should prob'ly be AFS.
What's going on there?

See my remarks above.  But by using -f you have suppressed the very
information I need; link counts.   What is the full stat information
for "theDir/.." ?

> For a while now findutils has been automatically turning off the leaf
> optimisation for directories where the link count is less than 2.   I
> would expect filesystems not honouring the traditional (but not
> standards-enforced) semantics of directory hard link counts should
> simply offer st_nlink=1 for directories.
> Are you seeing behaviour which isn't consistent with these
> assumptions?  If so, precisely what are you seeing?

I think this may be inconsistant, if I'm understanding this right:

address@hidden 246: stat -c %h theDir

The relevant thing is the link count on the directory containing
theDir, not the link count on theDir itself.

And just to make sure you know my RHEL4 system & versions.

address@hidden 180: uname -a
Linux prome.radonc.unc.edu 2.6.9-11.ELsmp #1 SMP Fri May 20 18:26:27 EDT
2005 i686 i686 i386 GNU/Linux

address@hidden 181: find --version
GNU find version 4.1.20

Findutils 4.1.20 was released in 2004.  People born since its release
can talk now.  Please upgrade, because otherwise I will not be able to
distinguish problems you are having now which are fixed from those
that are not.   In particular where I wrote "for a while now..."
above, I mean _since_ 4.2.24 (released in 2005).  In fact there is
quite a detailed explanation in the NEWS file in the entry for release

I can provide openafs client and server version numbers if you're

They would mean nothing to me.

Tell me if I can provide any more info.

Could you let me know if the bug is still present in any version of
findutils released _after_ I started growing hairs out of my ears?
4.1.20 is quite old now.   A suitably recent version would be 4.2.30,
though testing with 4.3.4 would also be useful.   Anything after
4.2.24 would be acceptable, though still potentially confusing, so
please shoot for 4.2.30.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]