Is there a way in Windows 7 to disable "journaling"?

^{Click for full size}

C:\$extend\$Usn.Jrnl:$J:$data

Here is a picture finally. The large strip in the center of the top band is the largest chunk, in the other, grey areas are the various clusters with it.

On the right, the big long grey line is $logfile (not paging), and it is 63 MB. Paging, 500 MB is the dark cyan chunk, next to the yellow MFTres in the inner rings.. The disk was defragged so they could be seen easier. Not all clusters of this type of file are tagged, but the idea is there.

The disk is 4k clusters, now about 12 GB size. Each cute little block in the picture is .81 MB and represents 207 clusters. The dkGreen section, is mostly the whole Winsxs pile, also interesting when they keep telling us it doesn't take much disk space.

Wikipedia suggests that in previous NT systems "USN journaling" would be turned on when enabled (assumes it could also be turned off?).

What aspects, services, or program is working on putting that stuff all over the disk which is known by $jrnl$ type clusters, even if it is not actual USN journaling?

Is it possible in a Windows 7 system to completly disable the journaling, and what would be the ramifications of that?

On a Windows XP NTFS system, I do not recall seeing the quantity of disk clusters used with these $jrnl$ names, so I do not recall this being necessary in this quantity for an NTFS file system itself?

I understand that it would not be there, if it did not have a useful function :-) Information about how wonderful is fine, if that information will help track down what parts of the system create and use it.

Change Journals states:

Change journals are also needed to recover file system indexing

Hmm, that might explain some of them, or why it was left on the disk. A crash while background indexing?

Solution 1:

There is a way to completely delete (not just disable) USN journal on Windows 7:

fsutil usn deletejournal /d c:

According to Microsoft Technet,

Deleting the change journal impacts the File Replication service (FRS) and the Indexing Service, because it would require these services to perform a complete (and time-consuming) scan of the volume. This in turn negatively impacts FRS SYSVOL replication and replication between DFS link alternates while the volume is being rescanned.

Same source above explains what USN journal is, and why it is needed:

The USN change journal provides a persistent log of all changes made to files on the volume. As files, directories, and other NTFS objects are added, deleted, and modified, NTFS enters records into the USN change journal, one for each volume on the computer. Each record indicates the type of change and the object changed. New records are appended to the end of the stream.

Programs can consult the USN change journal to determine all the modifications made to a set of files. The USN change journal is much more efficient than checking time stamps or registering for file notifications. The USN change journal is enabled and used by the Indexing Service, File Replication service (FRS), Remote Installation Services (RIS), and Remote Storage.

I suppose that if you don't use any of the services listed above, you can go ahead and delete the USN journal. And if you discover you need it later, you can re-create it using the same fsutil command (see the Technet link above for the complete syntax).

Update

I went ahead and tried to delete the USN journal on one of my "disposable" Windows 7 VMs. What happens is, the journal is indeed deleted, however it is re-created immediately (fsutil usn queryjournal c: confirms a new journal ID). I tried stopping Search service and others, but it didn't help. So I suppose while you could delete this journal, the usefulness of such deletion is rather limited.

Solution 2:

Technically, you can disable the USN change journal. The change doesn't look like it is persistence and at best looks like a liability for bugs.

Checking MSDN . ..

http://msdn.microsoft.com/en-us/library/aa363798(v=VS.85).aspx

To delete a change journal, use the FSCTL_DELETE_USN_JOURNAL control code. When you use this operation, it walks through all of the files on the volume and resets the USN for each file to zero. The operation then deletes the existing change journal. This operation persists across system restarts until it completes. Any attempt to read, create, or modify the change journal during this process fails with the error code ERROR_JOURNAL_DELETE_IN_PROGRESS. (Emphasis mine)

You can also use the FSCTL_DELETE_USN_JOURNAL control code to determine if a deletion started by some other process is in progress. For example, your application, when it is started, can determine if a deletion is in progress. Because journal deletions persist across system restarts, services and applications started at system restart should check for an ongoing deletion.

Change journals are not necessarily created at startup. To create a change journal, an administrator may do so explicitly or start another service that requires a change journal.

Solution 3:

Before you go disabling journals, keep in mind that once disabled, they are purged. From MSJ:

A Change Journal can be disabled on a given volume, preventing the system from logging file and directory changes. By default, an NTFS volume will have its Change Journal disabled. Some application must explicitly activate the journal. Also note that any application can activate or disable the volume's journal at any time. An application must be able to gracefully handle the situation when a journal is disabled while the first application is still using the journal. We'll describe how applications can handle this in a future article. When an application disables the Change Journal for a volume, the system will also purge any existing records to prevent recovery of the information. This prevents applications from inadvertently reading unreliable records. The journal will only contain records as long as the journal is continuously active.