From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <14ec7b180906091027g4c060b5egf0e15265289e5ee6@mail.gmail.com> Date: Tue, 9 Jun 2009 13:01:54 -0600 Message-ID: <14ec7b180906091201o71836512v464ae8edbbae436c@mail.gmail.com> From: andrey mirtchovski To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Different representations of the same file/resource in a synthetic FS Topicbox-Message-UUID: 0806b0ea-ead5-11e9-9d60-3106f5b1d025 > how are the resultant files looked up? =C2=A0it turns out that generating > the file hash table was the single most expensive operation for > upas/fs, given mailboxes with ~10k messages. > (http://9fans.net/archive/2009/05/106) 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. 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 :)