In ext2/journalless ext4 if you forget to umount the FS before rebooting/powering down PC you'll have to run fsck on a next boot. That's obvious. However we can easily avoid fsck'ing if we clean the dirty bit about a certain timeout (I suggest a configurable 300 seconds value) and only after dirty buffers have been flushed to the disk. If we write to the disk again, then this bit should be set again, of course.
This is an old proposal; the challenge which this is that if you do this, we then have to block any attempts to write to the file system until the dirty bit has been set in the superblock. It can be done, but it's not been a high priority to any of the ext3/ext4 developers. Patches to do this will be accepted. If someone wants more details about how to best do this and is willing to do the implementation and testing, please let me know.
I would also suggest looking at the per-group dirty bit that Val Henson developed, maybe 1.5 years ago. This allowed e2fsck to limit its boot-time scanning to only the small subset of groups/inodes that were modified shortly before the crash. I don't know how close to production-ready that code was, but it was at least at the working prototype stage. Some changes and updates are probably needed (e.g. changing the per-group flag value to avoid conflicting with other assigned flags) before using it on a newer kernel with ext4.
I didn't think Val had any code that was anywhere near working. As far as I know she never got around the design problem of what to do when you have a big file where the inode is in group #1, but it needs blocks in block groups #1, #2, #3, #4.... and what to do when you have a directory which has directory blocks that spans multiple block groups. She was going to design something complete new and incompatible from a format perspective, that had bidirection pointers, but I don't think this ever got to a working prototype stage as far as I know. Feel free to ask her, though....
Is it obsolete because no one wants to implement this feature or because Alan Cox thinks this feature request is meaningless?
It is obsolete because nobody has touched the bug for well over a year. The place to discuss it further and send patches is the mailing list (I'd love per inode group dirt bits!) Alan