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? -- 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/20141212234737.gh19...@copernicus.demon.co.uk
