Sean Liu writes:
> Hi Jim,
>
> Thanks for your reply, and that's good information.
> I actually did most of what you suggested.
> I started with dtrace and seems every system call takes longer to run
> on the filesystem when it is shared than not. So that's why I needed
> to understand what
J. Bruce Fields writes:
> On Fri, Aug 03, 2007 at 11:13:41AM +0200, Roch - PAE wrote:
> > Not a NFS expert but I would think giving a directory
> > delegation to a client doing the tar x would allow the
> > server to optimise this type of load; greatly.
>
&g
Keith Bierman writes:
>
> On Aug 2, 2007, at 3:55 PM, J. Bruce Fields wrote:
>
> > On Thu, Aug 02, 2007 at 03:50:19PM -0600, Keith Bierman wrote:
> >> Posit suitable battery backed up or nonvolatile cache. It would take
> >> collusion (thus consent ;>) of both the client and server;
> >
Peter C. Norton writes:
> On Wed, Aug 15, 2007 at 04:57:05PM -0700, adrian cockcroft wrote:
> > How fast do disks turn? You get one page per revolution. Adding more swap
> > disks would only help if there was more than one thread trying to read the
> > data. Ultra 1 had a nice fast 7200rpm SCS
adrian cockcroft writes:
> I think this is a good forum to discuss a systematic performance issue with
> swap. The problem has been there for a long time, I tried to get people
> interested in doing something about it around ten years ago, I left Sun in
> 2004 and don't even use Sun's at my c
adrian cockcroft writes:
> Why can't you adapt ZFS for swap? It does the transactional clustering of
> random writes into sequential related blocks, aggressive prefetch on read,
> and would also guard against corrupt blocks in swap. Anon-ZFS?
> Adrian
Good point. And It works already, swap to
Peter C. Norton writes:
> On Tue, Aug 21, 2007 at 05:34:38PM +0200, Roch - PAE wrote:
> >
> > adrian cockcroft writes:
> > > Why can't you adapt ZFS for swap? It does the transactional clustering
> > of
> > > random writes into seque
Bill Sommerfeld writes:
> On Fri, 2007-09-14 at 13:06 -0700, Alexander Kolbasov wrote:
> > Just being Devil's advocate. I don't doubt that you should be able to
> > improve the measurement significantly. I just think that the notion of
> > CPU utilization is a vague and processor dependent c
