Bug 23906

Summary: [PATCH] find -fstype local traverses non-local filesystems
Product: Base System Reporter: dima <dima>
Component: binAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
file.diff none

Description dima 2000-12-28 12:10:00 UTC
The '-fstype local' primary in find(1) is used to match files on a
local filesystem.  Among others, periodic(8) scripts use it to look
for files on local filesystems that have unknown user or group ids.
The problem is that although find(1) correctly doesn't match files on
remote filesystem when using the aforementioned primary, it still
traverses the remote filesystem.  This is a problem, for example, when
the noid periodic(8) script goes looking for files with unknown user
ids on remote filesystems.  The filesystem traversal causes
unnecessary load to the remote filesystem.

Fix: The attached patch causes '-fstype local' not to traverse a remote
filesystem.  In most cases, this should not affect the results
returned.  The only case I can think of where this may be undesireable
is when a local filesystem's mount point resides on a remote
filesystem (i.e., /path/to/nfs/filesystem/local is a local
mountpoint).  This is possible in theory, but I've never tried it; nor
can I think of why somebody would want to do that.
How-To-Repeat: 
For the purpose of this example, I will assume that a remote NFS
filesystem is mounted on /path/to/nfs/filesystem.

$ cd /path/to/nfs                  # don't add /filesystem!
$ find . -fstype local -print

find(1) will not match (and thus, won't print) files it finds on the
NFS server, but it is still traversing the tree.  You can use top(1)
or ps(1) on the NFS server to check that nfsd is consuming more
resources than it normally would if it were idle.
Comment 1 Garrett A. Wollman 2000-12-28 16:05:16 UTC
<<On Thu, 28 Dec 2000 04:08:00 -0800 (PST), dima@unixfreak.org said:

> The problem is that although find(1) correctly doesn't match files on
> remote filesystem when using the aforementioned primary, it still
> traverses the remote filesystem.

This is intentional, since a local filesystem might be mounted below a
remote one.  If you wish to prune non-local filesystems, the correct
syntax would be:

$ find / \( ! -fstype local -prune \) -o [what you really want to search for]

(POSIX unfortunately standardizes the broken `-xdev' and `-depth'
primaries, which should have been implemented as command-line options
and are in *BSD.)

-GAWollman

--
Garrett A. Wollman   | O Siem / We are all family / O Siem / We're all the same
wollman@lcs.mit.edu  | O Siem / The fires of freedom 
Opinions not those of| Dance in the burning flame
MIT, LCS, CRS, or NSA|                     - Susan Aglukark and Chad Irschick
Comment 2 dwmalone 2000-12-28 19:35:11 UTC
On Thu, Dec 28, 2000 at 04:08:00AM -0800, dima@unixfreak.org wrote:

> $ cd /path/to/nfs                  # don't add /filesystem!
> $ find . -fstype local -print
> 
> find(1) will not match (and thus, won't print) files it finds on the
> NFS server, but it is still traversing the tree.  You can use top(1)
> or ps(1) on the NFS server to check that nfsd is consuming more
> resources than it normally would if it were idle.

If I'm not mistaken, this is what the -prune option is for. If the
daily scripts don't use -prune then that's may be a bug in the
daily scripts I guess. You probably want to say something like:

	find . \( -fstype local -o -prune \) -print

As you point out, the daily scripts may just be extra cautious
by searching for local mount points within nonlocal file systems.

	David.
Comment 3 dima 2000-12-28 23:25:04 UTC
> On Thu, Dec 28, 2000 at 04:08:00AM -0800, dima@unixfreak.org wrote:
> 
> > $ cd /path/to/nfs                  # don't add /filesystem!
> > $ find . -fstype local -print
> > 
> > [find traveses /path/to/nfs/filesystem]
> 
> If I'm not mistaken, this is what the -prune option is for. If the
> daily scripts don't use -prune then that's may be a bug in the
> daily scripts I guess. You probably want to say something like:

Thanks for pointing this out.  I must've overlooked -prune.

Thank you for the quick reply.  You may close this PR.  I'll see what
I can do to the daily scripts to keep both groups (those who have
local filesystems mounted below remote ones and those who don't)
happy.

Regards

						Dima Dorfman
						dima@unixfreak.org
Comment 4 dwmalone freebsd_committer freebsd_triage 2000-12-29 12:32:33 UTC
State Changed
From-To: open->closed

Submitter says that -prune can do what they want.