Dirk Nitschke <dirk.nitsc...@sun.com> wrote:
> Solaris /usr/bin/find and Linux (GNU-) find work differently! I have
> experienced dramatic runtime differences some time ago. The reason is
> that Solaris find and GNU find use different algorithms.
Correct: Solaris find honors the POSIX standard, GNU find does not :-(
> GNU find uses the st_nlink ("number of links") field of the stat
> structure to optimize it's work. Solaris find does not use this kind
> of optimization because the meaning of "number of links" is not well
> defined and file system dependent.
GNU find makes illegal assumptions on the value in st_nlink for diretctories.
These assumptions are derived from implementation specifics found in historic
UNIX filesystem implementations, but there is no grant for the asumed behavior.
> If you are interested, take a look at, say,
>
> CR 4907267 link count problem is hsfs
Hsfs just shows you the numbers set up by the ISO-9660 filesystem creation
utility. If you use a recent original mkisofs (like the one that come with
Solaris since 1.5 years), you get the same behavior for hsfs and UFS. The
related feature has been implemented in October 2006 in mkisofs.
If you use "mkisofs" from one of the non-OSS-friendly Linux distributions like
Debian, RedHat, Suse, Ubuntu or Mandriva, you use a 5 year old mkisofs version
and thus the values in st_nlink for directories are random numbers.
The problems caused by programs that ignore POSIX rules have been discussed
several times in the POSIX mailing list. In order to solve the issue, I did
propose several times to introduce a new pathconf() call that allows to ask
whether a directory has historic UFS semantics for st_nlink.
Hsfs knows whether the filesystem was created by a recent mkisofs and thus
would be able to give the right return value. NFS clients need to implement a
RPC that allows to retrieve the value from the expoirted filesystem at the
server side.
> Am 17.06.2009 um 18:08 schrieb Louis Romero:
>
> > Jose,
> >
> > I believe the problem is endemic to Solaris. I have run into
> > similar problems doing a simple find(1) in /etc. On Linux, a find
> > operation in /etc is almost instantaneous. On solaris, it has a
If you ignore standards you may get _apparent_ speed. On Linux this speed
is usually bought by giving up correctness.
> > tendency to spin for a long time. I don't know what their use of
> > find might be but, running updatedb on the linux clients (with the
> > NFS file system mounted of course) and using locate(1) will give you
> > a work-around on the linux clients.
With NFS, things are even more complex and in principle similar to the hsfs
case where the OS filesystem implementation just shows you the values set up
by mkisofs.
On a NFS client, you see the number that have been set up by the NFS server
but you don't know what filesystem type is under the NFS server.
Jörg
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
joerg.schill...@fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
