Tell me more ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.
up vote 5 down vote favorite

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?

share|improve this question

2 Answers

up vote 4 down vote accepted

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.

share|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
up vote 2 down vote

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 seperate each operation and wait for the disk to acknowledge 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.

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

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.