On Mon, Feb 2, 2009 at 1:43 PM, Richard Elling <richard.elling at gmail.com> 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. >>>> >>>> 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 staff. Being able to cache all that data (perhaps by >>>> priming it) ensuring its not bumped out later would be interesting. >>>> >>>> >>>> >>> Does that include nameservice data? Doing an ls -l where the a files >>> owned by many users can be really slow. >>> >>> >> >> Good point... I hadn't considered that. >> > > ...and it is sorted, which may be more or less quick, depending > on your locale. > -- richard
Related to that, I have some changes I'll be attempting to putback (eventually) which includes the -U option in ls to prevent sorting of the filenames. If you want a preview, there's a webrev with the current work at http://cr.opensolaris.org/~jbk/shutils (it has a few other things, not sure yet if I'll attempt to put those back or not).
