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; > > > > No, it'd just mean you could respond to the commits more quickly, > > because part of your "stable storage" is lower-latency. No new > > protocol > > required. > > > > Unless I'm totally misunderstanding the suggestion. > > > > I was suggesting eliminating the COMITs entirely if the storage > device swears that there are no unprotected caches. One could imagine > you'd want to reserve COMIT for really causing magnetic rotating > storage involvement ;> >
The COMMITs are there to push data out of server host memory. So the commits can't really be avoided. Also many (maybe most) of the commits are initiated by the server itself. Fast NVRAM storage helps the problem a lot. The is nothing ZFS can change about this problem; However ZFS with Separate intent log (slog) will have a great way to use NVRAM based luns. 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. -r > Keith H. Bierman [EMAIL PROTECTED] | [EMAIL PROTECTED] > Strategic Engagement Team | AIM: kbiermank > 5430 Nassau Circle East | 650-352-4432 voice+fax > Cherry Hills Village, CO 80113 | 303-997-2749 > http://blogs.sun.com/khb | > <speaking for myself, not Sun*> Copyright 2007 > > > > > _______________________________________________ > perf-discuss mailing list > perf-discuss@opensolaris.org _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
