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 20:02:46 +0200
- Thread-topic: FSRef speed impacts and permission checks
On 15.05.2008 19:25 Uhr, "Mark Day" <email@hidden> wrote:
> First of all, CatalogSearch only has to check permissions on items
> that match your search criteria. A recursive walk has to check
> permissions for every object you visit
Err, I was speaking all the time of "scanning the entire volume", meaning
that of course all items match the search criteria. Thus, not a relevant
difference to my question.
> The recursive walk (using FSRefs) has to build and parse full paths
> for every item you visit. And it has to send you back enough data
> (from kernel to user space) for you to do matching in your app.
Again, this is not relevant because with CatalogSearch I am requesting the
same (full) set of data from a dir entry (names, catinfos, FSRefs), which is
the same I receive with the recursive Bulk call.
> In a recursive walk, it will read individual B-tree nodes
> (typically 8KB) as needed; they're often not sequential, so they may
> require the drive to seek to a different track.
Well, if it boils down to that, then I'm still not satisfied. Fact is that
in both cases _all_ data of the entire dir is retrieved exactly once (unless
there are extra internal read accesses to check parent permissions, but then
these should also be happening for both cases in the same amount).
When I call GetCatalogInfoBulk, that function has the freedom to return the
items in the order it prefers. And since on HFS nodes are ordered by their
name, seeking out the contents should still be rather sequential. I mean,
the nodes are directly indexed by the node ids, so if I provide a large
enough buffer to GetCatalogInfoBulk, it should be able to read all items of
that dir in one go, and pretty fast. Should not be much different to what
CatSearch runs into.
So, what really needs to be figured out is how many seeks the recursive
approach needs and if those extra seek times are all what makes it so much
slower. I could test this by writing my own code scanning the catalog, so
that I can be sure nothing else is going on. Or is there a kernel-level
logging facility that can tell me which sectors are read from disk so that I
can generate a profile from that?
Plus, I need to verify my suspicion that a root process does not require the
file system to check the permissions on the parent dirs: If I run the same
test from a non-root user, it must slow down pretty much to the speed of the
recursive search because it should require a similar amount of random
directory reads.
Agreed?
_______________________________________________
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