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.

-- 
New ext3 partitions should not have max-mount count
https://bugs.launchpad.net/bugs/3581
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to