I noticed that XFS does not implement a fsck at system boot and one of the reasons touted in that journaling file-systems help ensure the file-system is in a consistent state after an unclean shutdown; on the next mount (e.g. after reboot) the journal is replayed.

Is a fsck still needed after an unclean shutdown and why?


I'm answering this in the general context of "journalled filesystems".

I think that if you did a number of "unclean shutdowns" (by pulling the power cord or something) sooner or later you'd get to a filesystem state that would require fsck or the moral equivalent of fsck, xfs_repair. The ext4 fileystsm on my laptop for the most part just replays the journal on every reboot, clean shutdowns included, but every once in a while, it does a full-on fsck.

But ask yourself what "replaying the journal" accomplishes. Replaying a journal just ensures that the diskblocks of the rest of the fileystem match the ordering that the journal entries demand. Replaying a journal amounts to a small fsck, or to parts of a full on fsck.

I think there's some verbal sleight of hand going on: replaying a journal does part of what traditional fsck does, and xfs_repair is exactly what the same kind of program that e2fs.fsck (or any other filesystem's fsck) is. The XFS people just believed or their experience led them to not running xfs_repair on every boot, just to replaying the journal.

| improve this answer | |
  • 3
    Barring a bug in the journaling code or disk drive, no number of unclean shutdowns can leave the disk in a state that requires a fsck. ext[34] still retains the pedantic automatic fsck after so many mounts partly as a carryover from ext2 combined with, well... a pedantic attitude of "just in case". At least in recent versions of Ubuntu, this has been disabled by default. – psusi Jul 23 '12 at 1:35
  • From my experience, an automatic fsck is not 'pedantic'. I converted an ext3 LVM partition to ext4 and started getting 'ext4_mb_generate_buddy' errors due, as I understand, to a bug in the ext4 code which caused a mismatch in the on-disk and in-memory copies of the bitmap on converted 'LVM' partitions. As far as I can tell from fsck, no corruption occurred. The solution was either to turn off the UNINIT_BG option or move the data and reinitialised the partition as ext4; I took the latter course. But I still think a few minutes waiting for an fsck is worth not losing data! – StarNamer Jul 23 '12 at 12:04
  • 1
    There's a lot of missing informaion from this answer hence downvote and answer elsehwere. – symcbean Jul 23 '12 at 12:15

help ensure the file-system is in a consistent state after an unclean shutdown

First thing of note is that XFS, reiser and most configurations of ext only implement meta-data journalling, which is all about avoiding fsck. The journal is not always replayed on start up - it may be discarded if it's incomplete.

There are systems which support full data journalling - but in practice the level of assurance these give over just meta-data journalling is very small in real world scenarios.

So an 'inconsistent state', and the problems fixed by fsck, are mismatches between the meta-data and the files themselves. To avoid this, the OS writes out the proposed meta data changes to the journal, then writes the actual data to disk, then applies the meta data changes which are replicated in the journal to the disk. The only catch with this is that the disk controller will buffer and potentially reorder the requests. To avoid this, most journalling filesystems implement barriers: they separate each operation and wait for the disk to acknowledge that it has completed the operation. But many modern disks actually acknowledge completion of writes before the data is committed. Hence, things can get messy.

Is a fsck still needed after an unclean shutdown and why

Most filesystems maintain a mount count - once this count, is reached a full fsck will be triggered at the next attempt to mount the disk. The reason being that disk data may be corrupted even when it's not explicitly being written to, even without bugs in the software. psusi's comment above is wrong.

| improve this answer | |
  • You are conflating ordering with barriers. Disks do not report writes as completed before they have hit the disk unless you enable the write cache, which is disabled by default in consumer level disks, so with them, the fs just needs to wait for the one write to complete before issuing the next. For hardware with write caching, barriers are used to prevent reordering and force the disk to flush its write cache, thus keeping the fs from being corrupted. – psusi Jul 23 '12 at 13:30
  • 1
    psusi - what have you been smoking? " Disks do not report writes as completed before..." - yes they do. "enable the write cache, which is disabled by default" - not on any disk I've ever configured. "barriers are used to prevent reordering" - but you said I was "conflating ordering with barriers" – symcbean Jul 24 '12 at 18:06
  • No, they don't. If you do not enable the disk write cache ( hdparm -W ), then the disk does not complete write requests until it is on the medium. Why do you think that option exists? Barriers prevent reordering when multiple requests are issued. Without barriers, the fs simply does not issue more requests until the previous ones have completed, thus maintaining ordering without barriers... provided that the disk write cache is not enabled. The purpose of barriers is to allow you to enable the write cache, without corrupting the fs on a crash. – psusi Jul 24 '12 at 18:47
  • Oops, I got a little mixed up there and forgot about sync. Let me try again. The procedure for writing to the disk without barriers is to write to the journal, sync, thus flushing any write caches, then write the real data. This makes sure the journal can always be used to recover the fs after a crash, but syncing slows things down and half defeats the purpose of the write cache. Thus barriers were added as a better replacement to sync, and with the proper disk support, they can safely reclaim much of the performance the syncing takes away. – psusi Jul 24 '12 at 19:24

There is no need to fsck a journaling filesystem simply because of an unclean shutdown.

The entire reason for enduring the runtime performance penalty of metadata journaling is to ensure that the filesystem can be made 100% consistent again by automatically replaying the metadata log on the next mount, if the filesystem wasn't cleanly unmounted.

fsck's only role is to ensure metadata consistency, so it is redundant to run fsck simply because the filesystem wasn't properly unmounted.

A journaling filesystem can get corrupted for other reasons, though - hardware failure, driver bugs, admin errors, etc. - so fsck tools are certainly necessary. There's just no reason to invoke them solely due to an unclean shutdown.

| improve this answer | |
  • what about invoking them every 'n' reboots? useful? or just wait for an issue to be reported and then run fsck? – simpleuser Feb 5 '17 at 5:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy