Date: Tue, 10 Sep 1996 09:30:49 +0900 (JST) From: Michael Hancock <michaelh@cet.co.jp> To: Terry Lambert <terry@lambert.org> Cc: hackers@freebsd.org Subject: Re: namei performance (was Re: FreeBSD vs. Linux 96 (my impressions)) Message-ID: <Pine.SV4.3.93.960910092153.1234A-100000@parkplace.cet.co.jp> In-Reply-To: <199609082205.PAA03751@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 8 Sep 1996, Terry Lambert wrote: > Like I said in my previous posting, I think that cache locality in the > component name cache would more than make up for this. > > There is also the issue of multibyte support at the FS level, if you > want to get technical about it. If the path seperator is literal, then > each FS which wants to eat components will have to have an understanding > of seperator processing, etc. This has the unfortunate side effect of > locking you into a single path representation geometry. > > This fails for VFAT/VFAT32/HPFS/NTFS, all of which have "long names" > and 8.3 names for each file. For the Mac FS, it fails because of the > 32 character "short" Mac file name and the ProDOS name on each file, > and for the fact that the seperator character in the file name and out > is a null, not a '/' (you can hide this difference by translating > between '/' and ':' in the UNIX stored name for Mac clients of the FS). > I like the pre-parsing of the pathname into components idea for all these reasons. Freeing the code from delimiter processing is definitely a win. I also think the component list can be processed up to mount point by the underlying filesystem-dependent layer. The name cache is a central resource available to all file systems. It isn't necessary to have the processing go through the abstraction and the name cache can still be primed by component. Regards, Mike Hancock
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SV4.3.93.960910092153.1234A-100000>