From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <0ba7a2c75ada9aee91e80172ee7c3183@quanstro.net>
From: erik quanstrom <quanstro@quanstro.net>
Date: Tue,  9 Jun 2009 15:16:36 -0400
To: mirtchovski@gmail.com, 9fans@9fans.net
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Different representations of the same file/resource in
	a synthetic FS
Topicbox-Message-UUID: 0813bac4-ead5-11e9-9d60-3106f5b1d025

> still a hash. i'm not doing anything particularly clever for speed,
> and it shows in places. listing large directories is the slowest
> operation by far, as it would be for most cases where several thousand
> "stat" structures would have to be dynamically created for each entry
> in a directory. i'm not pre-generating anything however, so in daily
> use, where each client knows exactly where to go, i'm not seeing
> slowdowns.

thanks!

> not that i'm worried: we recently discovered a few misconfigured
> clusters around here (names withheld) that were using ldap and no
> local nameservice caching. each stat on those boxes would take 0.05 ms
> (instead of 0.005) to complete because it needed to contact a server
> for username lookup. the wait became unbearable above a number of
> thousands of files in a particular directory, so people finally
> started complaining after waiting for minutes for 'ls -l' to finish.
> things could be way worse, i guess :)

i suppose we could all be forced to reimplement vi for the
apollo landing computer.

- erik