On Feb 02, 2009 02:39 -0800, Ben Rockwood wrote:
> This is just a thought exercise but I'm curious what would exactly be
> involved in essentially biasing caching such that a 'ls -al' was never slow.
>
> In my experience, IO speed an vary, but if a user types "ls -al" in
> the shell and the r
Ben Rockwood wrote:
> This is just a thought exercise but I'm curious what would exactly be
> involved in essentially biasing caching such that a 'ls -al' was never slow.
>
> In my experience, IO speed an vary, but if a user types "ls -al" in the shell
> and the response isn't nearly instanta
On Mon, Feb 2, 2009 at 1:43 PM, Richard Elling
wrote:
> Ben Rockwood wrote:
>> Ian Collins wrote:
>>
>>> Ben Rockwood wrote:
>>>
This is just a thought exercise but I'm curious what would
exactly be involved in essentially biasing caching such that a 'ls
-al' was never slow.
>>
Ben Rockwood wrote:
> Ian Collins wrote:
>
>> Ben Rockwood wrote:
>>
>>> This is just a thought exercise but I'm curious what would
>>> exactly be involved in essentially biasing caching such that a 'ls
>>> -al' was never slow.
>>>
>>> In my experience, IO speed an vary, but if a user t
Ian Collins wrote:
> Ben Rockwood wrote:
>> This is just a thought exercise but I'm curious what would
>> exactly be involved in essentially biasing caching such that a 'ls
>> -al' was never slow.
>>
>> In my experience, IO speed an vary, but if a user types "ls -al" in
>> the shell and the res
Ben Rockwood wrote:
> This is just a thought exercise but I'm curious what would exactly be
> involved in essentially biasing caching such that a 'ls -al' was never slow.
>
> In my experience, IO speed an vary, but if a user types "ls -al" in the shell
> and the response isn't nearly instanta
This is just a thought exercise but I'm curious what would exactly be
involved in essentially biasing caching such that a 'ls -al' was never slow.
In my experience, IO speed an vary, but if a user types "ls -al" in the shell
and the response isn't nearly instantaneous they start calling IT s
