On Fri, 12 Dec 2014, Brian wrote: > On Thu 11 Dec 2014 at 22:04:56 -0700, Paul E Condon wrote: > > > On 20141211_1332+0000, Brian wrote: > > > > > > Multiply your experience by 10,000 or 100,000 similar accounts > > > and a picture begins to emerge and you can decide on how much > > > confidence you can place in a conclusion based on the accumulated > > > data. > > > > I did not contribute data to a growing pool of data on this > > situation, and a billion similar accounts from other users is ( 0 * > > 0 == 0 ) *no* data. > > You have a very strange idea of what constitutes data. Here are some > more data (or non-data if you prefer :) ), > > tune2fs(8) says > > You should strongly consider the consequences of disabling > mount-count-dependent checking entirely. Bad disk drives, cables, > memory, and kernel bugs could all corrupt a filesystem without > marking the filesystem dirty or in error. If you are using > journaling on your filesystem, your filesystem will never be > marked dirty, so it will not normally be checked. A filesystem > error detected by the kernel will still force an fsck on the > next reboot, but it may already be too late to prevent data loss > at that point. > > Very clear; mount-count dependent (or time-dependent) checking is > optional - but if you neglect doing it you run the risk of data loss. > > The changelog for e2fsprogs has > > Mke2fs will now create file systems that enable user namespace > extended attributes and with time- and mount count-based file > system checks disabled. > > This is very clear too; the standard e2fsprogs doesn't give you what > it strongly advises in tune2fs(8). The reason for the change in > e2fsprogs is that time- and mount count-based checks are not > particularly useful. > > > http://git.whamcloud.com/?p=tools/e2fsprogs.git;a=commit;h=3daf592646b668133079e2200c1e776085f2ffaf > > If the checks are not useful, why do them? Most Debian users with new > Wheezy or testing installs won't be doing them as a matter of course > anyway and their number will grow in the coming years. > > Are they any the worse off because these checks are not being made? > Has upstream got it wrong? Should some sections of the documentation > be rewritten? Or can default program behaviour and documentation be > reconciled?
I find "mount count" fs checks useless. You have to shutdown your system on a regular basis for it to be effective. My personal desktop system runs 24/7. I usually only shut it down 2 or 3 times a year. For cleaning. Guess I could set up "time between" checks, but I prefer to manually fsck. Easier. I just do this as root before shutdown -r now: touch /forcefsck On booting, fsck is run on all partitions, then the empty file forcefsck is deleted. So, this only works for that particular boot. I don't know how effective this check is though. But I've NEVER had a dirty partition reported in the past 8 years or so. The nice thing is it is a very fast check. My 16GB / checked in less than 5 seconds, and the 205GB /home in about 10 seconds or so. (I didn't actually time this. Subjective estimates.) However, it seemed TOO quick. Never thought about that until today when I actually sat there and watched the whole shutdown-reboot sequence. Usually I don't. Running a very custom Wheezy 64-bit install: 3GHZ quad-core AMD Phenom, 8GB RAM, Openbox WM only with a single LXPanel. B -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141212200726.18502...@debian7.boseck208.net