在windows vista打开Device manager(设备管理器),双击磁盘,在policies里面有个 Enable advanced performance(启用高级性能) 的checkbox,看看描述
[img][attach]2[/attach][/img]
Recommened only for disks with a backup power supply,This setting further improves disk performance,but it also increase the risk of data loss if the disk loses power. 哦.能提升磁盘性能,不过掉电的时候数据可能会丢,恩.笔记本有电池,这个没关系,赶紧打开这个选项,重启一下生效,用了几天感觉性能没有任何提升,测试一下磁盘效能,分数没有任何提高,不禁心生怀疑, 上网找了一下,心都凉了THIS FEATURE DOES NOTHING EXCEPT RE-INTRODUCE AN OLD WINDOWS BUG.
That’s right! There’s no performance increase available through this checkbox. It simply reintroduces an old bug that some old software relies on, so that said old software can regain the performance it lost when the bug was fixed. If you’re just an everyday average Joe like me trying to tweak your computer for the best performance, this checkbox isn’t going to help you. In fact, it’s going to hurt you, because if the disk loses power you could lose or corrupt your files.
这个功能性能没有任何提高,且会增加数据丢失的危险,这个只是一个windows的bug.一个windows 3.1.1 的bug在windows 2003中重演,提供这个选项是为了(还原旧有的错误行为)
具体可参看微软的文章,注意看最后一段
Windows 机密 错误的力量
Raymond Chen
在 Windows 95 中， 您可以进入“故障排除”页面选择“禁用同步缓冲提交”。但您知道这一复选框是干什么用的吗？或者为什么要这样做呢？
MS-DOS® Commit 功能的正常行为是将某一特定文件的所有未写入数据冲洗到磁盘，并等候直到确认数据已写入后才返回。当选中“禁用同步缓冲提交”选项时，调用将会立即返回，而不必等待数据的写入。当然，这违背了要求调用在数据写入后才能返回的功能规范。这增加了知识库文章 139669 中婉称为“文件完整性问题”的风险，因为它会导致程序发出冲洗请求，认为磁盘上的数据是安全的，但是事实上不是。
数据库程序可能使用“提交”功能来建立一些点，在这些点上，磁盘上文件的状态和程序所希望的状态一致。如果计算机在更新过程中断电，那么数据库程序可以使用最后提交点记录的信息来重新建立数据库的完整性。如果“提交”在提交未完成之前立即返回，则将会丢失此完整性检查点。后果是您的数据库会损坏。
如果后果是如此的糟糕，那为什么还提供此选项呢？原因是：在 Windows® 3.11 中有一个错误。
图 1 在 Windows Server 2003 中启用错误行为 (单击该图像获得较大视图)
Windows 3.11 引入了“32 位文件访问”，它是一个底层文件 I/O 接口的 32 位实施。但“提交”功能的实施包含一个错误，它有效地忽略了冲洗文件缓存的请求。如果您在 Windows 3.11 中运行程序来冲洗文件缓存，则冲洗调用无效。因此，如果您的计算机在不适当的时间断电，您将得到一个损坏的数据库。
Windows 95 文件系统的工作人员修复了这个错误，但是陆续产生新的错误报告。一些人的帐户支付程序运行开始变得非常缓慢。接着，其他人的数据库程序也出现了同样的问题。这是怎么回事？
原来，这些程序不断地发出冲洗调用。编程人员注意到在 Windows 3.11 中冲洗调用非常快，因此他们在程序中无限制地大量调用。写入一个字节，冲洗。写入一个字符串，冲洗。由于冲洗速度很快，因此应用程序可以在每次操作后将数据提交到磁盘，而没有注意到性能的降低。但是一旦 Windows 95 修复了这一错误，这些程序开始运行非常缓慢，因为这些提交的调用突然开始真正工作。
当然，如果文件系统小组没有做任何事，这些程序将会一直运行缓慢，而用户就会得出问题在于 Windows 95 的结论。“Windows 95 运行的非常慢”，他们将会这样告诉其他人。另一方面，如果文件系统还原到旧版的 Windows 3.11 行为，则它们将再次引入将会导致这些讨厌的“文件完整性问题”的错误。
所以他们的结论是，修复这个错误但增加一个复选框（虽然隐藏在“故障排除”页面），以便让运行程序时遇到因为修复错误而引起问题的人们返回到 Windows 3.11 行为。
事实证明，历史经常重演。在 Windows Server® 2003 中，I/O 人员发现了一个错误，即标记为“Forced Unit Access (FUA)”的请求会丢失 FUA 标记并作为正常 I/O 执行。它是忽略冲洗请求的“现代版”！他们修复了该错误，但是留下了返回到旧的错误行为的选项。此复选框的 Windows Server 2003 版本称为“启用高级性能”，但现在您知道它的真实含义是“还原旧的错误行为”。
Windows Confidential The Power of Bugs (windows 机密,错误的力量)
http://technet.microsoft.com/en-us/magazine/cc162475.aspx
In Windows 95, you could go to the Troubleshooting page and select Disable Synchronous Buffer Commits. But do you know what this checkbox did? Or why?
The normal behavior of the MS-DOS® Commit function was to flush all unwritten data for a particular file to disk, and wait until the data had been confirmed as written before returning. With the Disable Synchronous Buffer Commits option checked, the call would return immediately, rather than waiting for the data to be written. This, of course, was a violation of the functional specification, which requires that the call not return until the data has been written. This increased the risk of what Knowledge Base article 139669 euphemistically calls “file integrity problems” since it caused the program that issued the flush request to think that the data was safely on disk when it really wasn’t.
A database program may use the Commit function to establish points at which the state of the file on disk is in agreement with what the program expects to be on the disk. If the computer loses power during an update, the database program can use the information recorded at the last commit point to re-establish the integrity of the database. If Commit returned immediately before the commit was complete, then this integrity checkpoint would be lost. The result was that your database became corrupted.
Why was this option available if the consequences were so awful? The reason: a bug in Windows® 3.11Windows 3.11 introduced “32-bit file access,” which was a 32-bit implementation of the low-level file I/O interface. But the implementation of the Commit function contained a bug that effectively ignored requests to flush file buffers. If you took a program that flushed its file buffers and ran it on Windows 3.11, the flush call had no effect. As a result, if you lost power at just the wrong time, you ended up with a corrupted database.
The folks working on the Windows 95 file system fixed this bug, but new bug reports started to trickle in. Somebody’s accounts payable program started running really slowly. Then somebody else’s database program did the same. What was going on?
It turned out that these programs constantly issued flush calls. The programmers noticed that flush calls were really fast on Windows 3.11, so they sprinkled them liberally throughout their program. Write a byte, flush. Write a string, flush. Since the flushes were so fast, the app could commit the data to disk after every operation with no noticeable performance degradation. But once Windows 95 fixed the bug, these programs started to run very slowly since the Commit calls were suddenly doing actual work.
Of course, if the file system team had done nothing, these programs would have continued to run slowly and users would have jumped to the conclusion that Windows 95 was the problem. “Windows 95 runs like a dog,” they would tell others. On the other hand, if the file system returned to the old Windows 3.11 behavior, they would have been reintroducing a bug that could lead to those pesky “file integrity problems.”
So they concluded that the solution was to leave the bug fixed but add a check-box—albeit buried in the Troubleshooting page—to return to the Windows 3.11 behavior for those people who were running programs that encountered problems due to the bug being fixed.
It turned out that history repeated itself. In Windows Server® 2003, the I/O folks found a bug where requests tagged as Forced Unit Access (FUA) would lose the FUA tag and be performed as normal I/O. It was the modern-day version of ignoring flush requests! They fixed the bug but left an option to return to the old buggy behavior. The Windows Server 2003 version of this checkbox is called “Enable Advanced Performance,” but now you know it really just means “Restore old buggy behavior.”