> >> I'd like to see this one also considered for 8.0.x, though I'd > >> certainly like to see some more testing as well. Perhaps it's > >> suitable for the "8.0.x with extended testing" that is planned for > >> the ARC replacement code? > >> > >> It does make a huge difference on win32. While we definitly don't > >> want to risk data, a 60% speedup in write intensive apps > is a *lot*. > > > > Notice we never default to open_sync. However, on Win32, > Magnus got a > > 60% speedup by using open_sync, implemented using > > FILE_FLAG_WRITE_THROUGH. Now, because this the fastest on Win32, I > > think we should default to open_sync on Win32. The attached patch > > implements this. > > Considering how stable an Operating System Windows *isn't*, I
The difference has nothing to do with the stability of the OS. It has to do with wether we ignore the *hardware* write cache or not. Both methods ignore the OS write cache. > think the first thing Magnus states very much goes against > making this the default: > "While we definitely don't want to risk data..." ... > > Setting something like this that increases the risk to data > should never be 'the default behaviour', but a conscious > decision on the part of the administrator of the individual > system ... and even then, with a good skull-n-cross bones > warning around it so that they understand the risks ... The same level of "risk due to write cache" exists on all other operating systems already. (Actually, I only know it exists on linux, but it sure looks like it exists on most others looking at performance figures) //Magnus ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
