On Thu, 2009-04-30 at 16:41 -0400, Peter Staubach wrote: > Chuck Lever wrote: > > > > On Apr 30, 2009, at 4:12 PM, Brian R Cowan wrote: > >> > >> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ab0a3dbedc51037f3d2e22ef67717a987b3d15e2 > >> > Actually, the "stable" part can be a killer. It depends upon > why and when nfs_flush_inode() is invoked. > > I did quite a bit of work on this aspect of RHEL-5 and discovered > that this particular code was leading to some serious slowdowns. > The server would end up doing a very slow FILE_SYNC write when > all that was really required was an UNSTABLE write at the time. > > Did anyone actually measure this optimization and if so, what > were the numbers? As usual, the optimisation is workload dependent. The main type of workload we're targetting with this patch is the app that opens a file, writes < 4k and then closes the file. For that case, it's a no-brainer that you don't need to split a single stable write into an unstable + a commit. So if the application isn't doing the above type of short write followed by close, then exactly what is causing a flush to disk in the first place? Ordinarily, the client will try to cache writes until the cows come home (or until the VM tells it to reclaim memory - whichever comes first)... Cheers Trond -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
