From: ty...@mit.edu
On Mon, May 24, 2010 at 03:11:23PM -0700, Elliott Mitchell wrote:
If you hate precautionary checks so much, then turn them off. The
tools for doing this are within your hands. Or do them using a LVM
snapshot.
I don't hate precautionary checks. The problem is my
On Thu, May 27, 2010 at 05:58:12PM -0700, Elliott Mitchell wrote:
Oy vey! I'm inclined to suggest that if this really does happen, that
sounds like a bug... I could understand funky occurances if after
reloading, the kernel can no longer find the FS data structures (device
was erased), but
Any update?
Should /I/ create a second bug report and attach it to util-linux? (or
are you going to do the honors?) Thought I saw the current BTS can have a
report shared amoung multiple packages...
The algorithm that comes to mind for this problem:
Pass 0: (/etc/init.d/checkroot.sh)
On Mon, May 24, 2010 at 03:11:23PM -0700, Elliott Mitchell wrote:
Any update?
I continue to think this is hopelessly complex and not worth the
effort.
If you hate precautionary checks so much, then turn them off. The
tools for doing this are within your hands. Or do them using a LVM
snapshot.
From: ty...@mit.edu
If you are mounting the file system read-only, feel free to change the
fsck pass number in /etc/fstab to be 0. That will cause e2fsck to be
skipped completely.
Wrong behavior. The desire here is not to disable checks due to being on
read-only media, but the filesystem is
On Thu, Mar 25, 2010 at 12:55:50AM -0700, Elliott Mitchell wrote:
Which is why I wasn't writing about the mount count. I was writing about
the check interval/check time. With systems that reboot less than once a
month, the mount count will never be reached. Instead it will be the
check
From: ty...@mit.edu
On Thu, Mar 25, 2010 at 12:55:50AM -0700, Elliott Mitchell wrote:
Which is why I wasn't writing about the mount count. I was writing about
the check interval/check time. With systems that reboot less than once a
month, the mount count will never be reached. Instead it
Package: e2fsprogs
Version: 1.41.3-1
Subject tells the story. Why are mere /precautionary/ filesystem checks
allowed to slow a system booting so much? ie the ones triggered by either
the mount count or check time exceeding their limits.
I would suggest limiting it to doing a precautionary check
On Wed, Mar 24, 2010 at 05:29:58PM -0700, Elliott Mitchell wrote:
Package: e2fsprogs
Version: 1.41.3-1
Subject tells the story. Why are mere /precautionary/ filesystem checks
allowed to slow a system booting so much? ie the ones triggered by either
the mount count or check time exceeding
9 matches
Mail list logo
