Why does a journal filesystem need to check disk?

6

2

After I got the BSOD on my Windows 7 computer, I restarted my computer to find it asking me to do a disk check. I did other things in the meantime but it seemed like it took a few minutes.

If the filesystem is journalled (I left it to the default which is NTFS) why does it need to check the disk after my crash?

user3109

Posted 2011-12-31T11:15:16.500

Reputation:

Answers

6

Because journalling is not a magic wand.

Coping with power outages and system crashes during I/O transactions doesn't become a non-issue just because a journal of transactions is kept. The part-completed transactions that were in progress when the system crashed/the power went out don't get magically rolled forward or rolled back by themselves. The rolling forward/back has to be done before/as the volume is remounted when the system comes back up again. That happens as part of the disc checking process.

Filesystem journalling makes it simple to restore a self-consistent state. It doesn't magically cause the disc volume to never be in an inconsistent state when the dirty shutdowns occur in the first place.

JdeBP

Posted 2011-12-31T11:15:16.500

Reputation: 23 855

Ok thats reasonable but this was optional. I was allowed to skip it with a keypress. Also it took minutes while rolling back a change should not. (But remember i was still able to skip the check...) – None – 2012-01-03T02:51:25.477

3

Journal allows to bring filesystem quickly to consistent state after unclean shutdown but not when corruption occurs due to hardware failure or system error. In such case a full check is required.

x22

Posted 2011-12-31T11:15:16.500

Reputation: 421

@acidzombie24 What do you expect to happen if there is a write error while rolling back an uncommitted journal entry? Obviously the rollback fails and it can leave the file system in an inconsistent state. – doug65536 – 2016-09-29T13:51:04.700

1

Because a write or writes are not completed to the drive, The OS (not in existance now) has no way of knowing that the drive completed writes. . The dirty bit is set on the drive (itself) until it is cleared, by a proper finish. . Data from a Journal write itself can be a half written corruption point, negating the whole idea that the journaling actually helps on non-critical things. (I am somewhat biased) I would prefer that it finish in one move, and let me worry about what is lost.

The journaling could save/recover the data that was on its way, and maintain the pointers to the data , keeping one aspect of it straight. It cannot fix any bad/incomplete writes to the hard drive.


The USN change journal is enabled and used by the Indexing Service, File Replication service (FRS), Remote Installation Services (RIS), and Remote Storage. http://technet.microsoft.com/en-us/library/cc788042(WS.10).aspx

Change journals are also needed to recover file system indexing—for example after a computer or volume failure. The ability to recover indexing means the file system can avoid the time-consuming process of reindexing the entire volume in such cases. http://technet.microsoft.com/en-us/query/aa363798

Psycogeek

Posted 2011-12-31T11:15:16.500

Reputation: 8 067

-1, that's just not how journalling works. When restarted, yhe OS can detect that a write started (journal contains a write-started entry) and did not finish (missing the matching write-completed entry). – MSalters – 2012-01-02T14:46:34.073

@MSalters they do infact use a "dirty bit" to indicate when chkdsk should be run.

– Breakthrough – 2012-01-02T15:40:35.957

1That's true, and I didn't dispute that part. But that bit is just a quick check to prevent chkdsk from starting at all. I.e. if it is not set, then you don't need to check the jornal at all. This optimizes the boot time for the non-crashed case. The question was about the BSOD case, though, and then the journal matters. And there Psycogeek's description of the journal just doesn't make sense. With an incomplete journal record (missing end indicator), you can fix an incomplete write by means of a rollback. – MSalters – 2012-01-02T15:52:49.207

Your all correct, my answer is obscure trying to cover different levels of "journaling", like indexing , and other stuff that is beyond me. The answer needs a whole book. To honestally say that the answer is incorrect, and that "journaling" in a windows system is limited to meta-data , when it is used for Indexing and who knows what else. In that case is more than metadata, and is also recoverable. If you have not seen what is all on the disk, and all the things being done, I am no expert, But I didnt disreguard things that are happening there. – Psycogeek – 2012-01-03T00:05:07.523

I specifically stated, that writing a journal entry could be the point of corruption itself. and you logically return with "journaling is perfect" But the failed writing of the journal itself, never comes to mind? How exactally would it know it completed that write(s), if in the middle of it telling it that data is now complete, it Failed, it corrupted its own write? If you can explain that. Then searching for corrupted USN journal should come up with nothing at google? – Psycogeek – 2012-01-03T15:31:30.413

1

Journalling comes in different levels, which have different trade-offs. NTFS journals only meta-data, not the actual file contents itself. That means that you can corrupt single files while writing, but you can't corrupt the other files in the same directory.

Similarly, when a crash does happen, the exact type of jornalling determines how much time is needed to actually fix the disk. Again, there's a tradeoff: if you structure the jornal so fixing is easy, you'll spend more time in regular disk writes. Since BSODs are fairly rare, NTFS is optimized for the non-crash case, which means that recovering from a journal is slower.

MSalters

Posted 2011-12-31T11:15:16.500

Reputation: 7 587

BSODs are fairly rare Not if you cheat by using NTFS.sys under 98SE or ME. :) – user2284570 – 2013-12-17T21:42:14.253

0

In a journal-based file system, all changes to your files are recorded and held together. This allows the separation of file contents from the metadata (filename, modified dates, etc...). The implications of this, however, are that if a file is not indexed in the journal, it literally doesn't exist - even if the 0's and 1's physically exist on the platter.

This is where chkdsk comes in handy, as well as the "dirty bit" of the drive. When performing various file system operations, the dirty bit is set until the operation is completed, at which point it is cleared. From the Microsoft fsutil documentation:

If a volume's dirty bit is set, this indicates that the file system may be in an inconsistent state. The dirty bit can be set because the volume is online and has outstanding changes, because changes were made to the volume and the computer shutdown before the changes were committed to disk, or because corruption was detected on the volume. If the dirty bit is set when the computer restarts, chkdsk runs to verify the consistency of the volume.

Since your computer had the dirty bit set, you need to ensure that the filesystem is consistent to prevent volume corruption, or data loss. Running a file system checker can also allow the drive to recover non-indexed files which haven't yet been recorded in the journal.

Breakthrough

Posted 2011-12-31T11:15:16.500

Reputation: 32 927