Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Picture of location of clusters
Click for full size


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&nbsb;MB. Paging, 500&nbsb;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?

share|improve this question
There are many reasons for the more journal entries. One can be if the disk is being accessed more, this is very possible with Windows 7 over XP. How much RAM do you have in this system, check to see the number of background tasks that are running for all users and post that as well. How much space / clusters are being taken up by $jrnl$ clusters in 7 and if you looked at XP, please post for comparisons sake. – Dustin G. Oct 9 '11 at 0:17
What application were you using when you saw "crap everywhere"? and could you describe this crap? or is it just the $jrnl$ stuff? – Dustin G. Oct 9 '11 at 14:10
Those super duper defrag utilities don't do a whole lot for you except keep people with OCD up at night when they find that one cluster just didn't move into an "optimal" location. With files of that size, you're not going to see any performance penalties even if they are blocking a larger file from being contiguous. Using a third-party defragmenting utility isn't as beneficial as it was 7-10 years ago. Look at the pretty colors while it runs and don't waste your time worrying about the little things... – Dustin G. Oct 10 '11 at 6:01
2 true. I can just get a SSD and be done with it. Look at this pic… Does it seem like the system is doing things the way I want? I was going to process those 1 million pics, and I was also going to be storing more video data on that disk, that needs sequentiality. – Psycogeek Oct 10 '11 at 17:45
I removed my comments to the question itself (picture). Sometimes this kind of information is useful beyond the Psudo performace , to understanding what is going on , what breaks and how . . . did I break it :-) – Psycogeek Oct 12 '11 at 4:19

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).


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.

share|improve this answer
Thanks, the Indexing is going away, FRS I do not understand at all. I also do not understand why I could not Run something, to Finish this activity which would take about 2 minutes total. They drag things on forever so they dont effect performance, then have to redundant it, because it takes so long. Thier own Ketch22. – Psycogeek Oct 12 '11 at 3:26
Thanks for testing , if it is recreated at the least it is seqeuntial for a while. . Is it strange that other locked I/O important files have previously been oversized and locked in place. like the MFT reserve. Just strange to me, OCD :-). – Psycogeek Oct 12 '11 at 3:48
Any idea if this automatic recreate behaviour exists on other Windows OSs? – Cocowalla Apr 3 '12 at 18:46

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 . ..

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.

share|improve this answer
If I could comprehend what MS writes I wouldnt have asked. :-) I dont suppose you could say that in english? It only took a short period of time to delete them all with the Fsutil? Are you saying with the right programming it could be Suspended for a while? (I am not a programmer) – Psycogeek Oct 4 '11 at 10:11
It says at any time another service can start the change journal back up. So yes. So essentially at best, it is suspended until the next process or service decides to start it back up. – surfasb Oct 4 '11 at 23:39
@surfasb Deleting the contents of the USN journal is not disabling it. Microsoft provided the facility you posted to delete the contents of the journal if it is getting too big, and once the delete process is done, then NTFS will start writing to it again. – Dustin G. Oct 9 '11 at 14:13
@DustinG.: Yeah, I figure there was no way Microsoft would spend time testing such a niche feature. – surfasb Oct 10 '11 at 2:12

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.

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .