Comment 17 for bug 3581

First off, a periodic fsck does not address the problem of data integrity. It's there to make sure that the filesystem is consistent. It's just a repair _attempt_ that occurs long after the damage has been done.

Anyway, both data integrity and filesystem consistency are just fine with Ext3 on modern 2.6 kernels - look at the pretty large community using (just to pick the RH-based distros) Fedora, Red Hat and CentOS, those distributions disable the fsck and if that was a problem, it will surely show up in their bug reports. That, of course, does not happen. What is the logical conclusion?
As for my personal experience - I used Fedora since version 1 on laptops, no problem, despite some fairly stupid things I did with the file systems. I just recently migrated to Ubuntu and now I have to sit through useless fscks that waste my time and drain the battery and do nothing otherwise.

For the exceedingly paranoid, fine, keep it as an option. But don't _force_ it upon everyone else.

The installer should provide this as an option somewhere. The user should be allowed to choose whether the system should perform fsck every X reboots, how big is X, or even allow the user disable fsck altogether.
If that is implemented as a choice, my preference for the default setting would be to disable fsck, but I don't care very much about that as long as I can choose.
If it's deemed too abstract for the regular user, fine, hide it behind an "Advanced Settings" menu or screen.
Like ma2412ma suggested, also adding this as an option to the control panel or something like that would be great.

If you are that worried about data integrity, read up on filesystems and consider the more realistic choices. Periodic fsck does not address your worries. What you actually need in that case are things such as:
1. disable the write cache at the disk/controller level
2. mounting the filesystems with the "sync" option
3. mounting Ext3 with the "data=journal" option
Option #1 is probably the most efficient to keep your data safe and the filesystem sane. But it slows down the disk quite a lot.
Option #2 is the next best thing. Still slow.
Option #3 is probably just as good as #2 in terms of data integrity, probably less good in terms of filesystem consistency, and probably significantly faster than #1 and #2 (but still slower than the default - except in fringe cases such as Postfix spools when some users benchmarked higher performance with data=journal for some reason).

Of course, a simple technique such as periodic backups is more efficient than all the software tricks in the world.