Dear All,
Credits first :-). So, thanks for all who replied:
Brad Young <bbyoung@amoco.com>
Kevin Sheehan <u-kevin@veritas.com>
Max Trummer <max@sequana.com>
Cooke, Earl R. <COOKEEA@mail.northgrum.com>
Bismark Espinoza <bismark@alta.jpl.nasa.gov>
Mark Conroy <mark_conroy@em.fcnbd.com>
Birger Wathne <birger@sdata.no>
Zsolt Habony <Zsolt.Habony@Hungary.Sun.COM>
The final answer were given by Zsolt Habony (Support Engineer Enterprise
Services Sun Hungary). So, thank you, Zsolt!
So, the answer is, that in Solaris 7 there is *NO* 30 characters limit in
the record size of DNLC.
There was a consensus on keeping busy filesystems on short pathnames.
I quote from Zsolt's letter:
---------------------------------------------------------------------------
>In Solaris 7 the mechanism how the DNLC is operated has changed from
>a simple lookup to some kind of hashed lookup. It is now able to cache
>filenames of any size, for all I know, as the filenames themselves are
>no longer stored in the DNLC.
>There is a new DNLC implementation in Solaris 7 that dynamically
>allocates each entry to be the right size. Overall this saves space as
>it doesn't preallocate lots of 30 byte entries, and it also allows
>the maximum pathname component size of 255 to be cached so there are no
>more toolongs.
---------------------------------------------------------------------------
Furthermore, I think that the comments from Kevin are also valuable to
share with you:
---------------------------------------------------------------------------
It is *always* better to keep names shorter than the 31 character limit to
make sure the DNLC is used to cache the node for lookups and such. (14 chars
on 4.x BTW). If nodes are *not* DNLC cached you may lose them unnecessarily
and have to do I/O to recover pages as well as meta-data.
Shorter names take less time to compute the hash value as well, but that
is much less of an issue.
Long absolute path names mean that every component has to be looked up
individually on the way down - but you have less members per directory
in general.
Lots of names in a directory mean that you have a longer linear search time
but less of a path name cost.
So, when you open/lookup a file, you should do it relative, not
absolute if possible and there is a tradeoff between path length and
number of entries in a directory for performance.
---------------------------------------------------------------------------
Cooke, Earl R. noted:
---------------------------------------------------------------------------
There are at least two NFS request / sub_dir, so yes short paths are always
faster.
---------------------------------------------------------------------------
Bismark said:
---------------------------------------------------------------------------
In terms of saving computer cycles when resolving the pathname,
the shorter mount point is better.
However, the DNLC is for recently-read directories entries.
If the directory is accessed heavily, the entry will reside
in the DNLC, regardless of pathname.
---------------------------------------------------------------------------
Birger thought it right:
---------------------------------------------------------------------------
I think dnlc caches long names as well in Solaris 7. Read the what's new
section in the manual.
---------------------------------------------------------------------------
Thanks for all.
Cheers,
Bertold
-- Bertold Kolics * Computer and Automation Research Institute * Hungary E-Mail: Bertold.Kolics@sztaki.hu * Phone: +36-13497532 * Fax: +36-13297866
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:13:14 CDT