Windows 7 中有没有办法禁用“日志记录”？
Psy*_*eek 8 windows-7 journaling
C:\$extend\$Usn.Jrnl:$J:$data
这是最后一张照片。顶部带中心的大条带是最大的块，在其他灰色区域中是各种簇。
在右边，大长灰线是$logfile（不是分页），它是 63 MB。分页，500 MB 是深青色块，内环中的黄色 MFTres 旁边.. 磁盘碎片整理，以便可以更容易地看到它们。并非所有此类文件的集群都被标记，但想法就在那里。
磁盘是 4k 集群，现在大约 12 GB 大小。图中每个可爱的小方块大小为 0.81 MB，代表 207 个簇。dkGreen 部分主要是整个 Winsxs 堆，当他们不断告诉我们它不占用太多磁盘空间时也很有趣。
维基百科建议，在以前的 NT 系统中，“USN 日志”将在启用时打开（假设它也可以关闭？）。
哪些方面、服务或程序正在努力将这些东西放在$jrnl$类型集群已知的磁盘上，即使它不是实际的 USN 日志？
在 Windows 7 系统中是否可以完全禁用日志功能，这会产生什么后果？
在 Windows XP NTFS 系统上，我不记得看到使用这些$jrnl$名称的磁盘簇的数量，所以我不记得在这个数量中这对于 NTFS 文件系统本身是必要的吗？
我知道它不会在那里，如果它没有有用的功能:-) 关于多么美妙的信息很好，如果该信息有助于追踪系统的哪些部分创建和使用它。
更改日志指出：
还需要更改日志来恢复文件系统索引
嗯，这可以解释其中的一些，或者为什么它留在磁盘上。后台索引时崩溃？
有一种方法可以在 Windows 7 上完全删除（不仅仅是禁用）USN 日志：
fsutil usn deletejournal /d c:
据微软技术网报道，
删除更改日志会影响文件复制服务 (FRS) 和索引服务，因为这需要这些服务对卷执行完整（且耗时）的扫描。这反过来会对 FRS SYSVOL 复制和重新扫描卷时 DFS 链接交替之间的复制产生负面影响。
上面的相同来源解释了什么是 USN 期刊，以及为什么需要它：
USN 更改日志提供对卷上文件所做的所有更改的持久日志。随着文件、目录和其他 NTFS 对象的添加、删除和修改，NTFS 会将记录输入到 USN 更改日志中，计算机上的每个卷都有一个记录。每条记录指示更改的类型和更改的对象。新记录被追加到流的末尾。
程序可以查阅 USN 更改日志以确定对一组文件所做的所有修改。USN 更改日志比检查时间戳或注册文件通知更有效。USN 更改日志由索引服务、文件复制服务 (FRS)、远程安装服务 (RIS) 和远程存储启用和使用。
我想如果您不使用上面列出的任何服务，您可以继续删除 USN 日志。如果您以后发现需要它，您可以使用相同的fsutil命令重新创建它（有关完整语法，请参阅上面的 Technet 链接）。
更新
我继续尝试删除我的一个“一次性”Windows 7 VM 上的 USN 日志。发生的情况是，日志确实被删除了，但是它会立即重新创建（fsutil usn queryjournal c:确认新的日志 ID）。我尝试停止搜索服务和其他服务，但没有帮助。所以我想虽然你可以删除这个期刊，但这种删除的用处是相当有限的。
从技术上讲，您可以禁用USN 更改日志。这种变化看起来不像是持久性的，最多看起来像是对错误的责任。
检查MSDN。..
http://msdn.microsoft.com/en-us/library/aa363798(v=VS.85).aspx
要删除更改日志，请使用 FSCTL_DELETE_USN_JOURNAL 控制代码。当您使用此操作时，它会遍历卷上的所有文件并将每个文件的 USN 重置为零。然后该操作将删除现有的更改日志。此操作在系统重新启动后持续存在，直至完成。在此过程中任何读取、创建或修改更改日志的尝试都会失败，并显示错误代码 ERROR_JOURNAL_DELETE_IN_PROGRESS。（强调我的）
您还可以使用 FSCTL_DELETE_USN_JOURNAL 控制代码来确定由其他进程启动的删除是否正在进行中。例如，您的应用程序在启动时可以确定是否正在进行删除。由于日志删除在系统重新启动后仍然存在，因此系统重新启动时启动的服务和应用程序应检查是否有正在进行的删除。
变更日志不一定是在启动时创建的。要创建更改日志，管理员可以明确执行此操作或启动另一个需要更改日志的服务。