Re: FSRef speed impacts and permission checks
Re: FSRef speed impacts and permission checks
- Subject: Re: FSRef speed impacts and permission checks
- From: Thomas Tempelmann <email@hidden>
- Date: Thu, 15 May 2008 09:31:31 +0200
- Thread-topic: FSRef speed impacts and permission checks
On 15.05.2008 2:29 Uhr, "Mark Day" <email@hidden> wrote:
> In current versions of Mac OS X (I think 10.4 and later), the volfs
> file system was removed. Now, volfs-style pathnames are parsed by VFS
> and turned into a full pathname inside the kernel (by walking up the
> vnodes' parent pointers). Then it walks down the path as if the
> caller had passed a full pathname, which lets us leverage the existing
> permission checks. (As Dominic pointed out, there is caching to
> reduce the cost of those permission checks.)
Is there maybe an optimization that skips this whole permission checking if
the caller is root?
I wonder because when I run my FSCatalogSearch over all items on a volume
that contains 5 million items, it does that in less than 4 minutes. That
looks to me like a straight walk over the directory file without random
reads for parent permissions.
OTOH, when I scan the same volume recursively, even with the
FSGetCatatalogInfoBulk function, scanning becomes much much slower.
I understand that the catalog file is a B*Tree and that it's ordered mainly
by a dir's NodeID.
So, while the order of visited dirs is different between CatSearch and
recursive search, the latter should actually be faster because its parent
dirs have been visited rather recently, making it more likely to be still
cached, while with catsearch, it's all pretty random, so reading the parent
dir entries is less likely to be cached as well.
Can you explain that?
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden