On 20/08/07, Ian Smith <[EMAIL PROTECTED]> wrote:
> Sorry for the repeat post folks, but I goofed last time, leaving out the
> subject line while replying to the digest. Still curious .. Ian
> On Sat, 18 Aug 2007 21:32:28 +0200 Erik Trulsson <[EMAIL PROTECTED]> wrote:
> > On Sat, Aug 18, 2007 at 08:21:42PM +0100, Christopher Key wrote:
> > > Hello,
> > >
> > > I'm having some rather strange behaviour with fsck.
> > >
> > > When I boot the system, it asserts that all the file systems are clean,
> > > subsequently running an fsck on /dev/ad8s1e (mounted as /var) detects
> > > errors. Even if this first check is run whilst the file system is
> > > and is hence run in NO WRITE mode, a second check doesn't find block
> > > errors. If I then unmount the file system and check the disk, it's fine,
> > > as indeed it is if I unmount, remount, then check. However, if I then
> > > reboot, the process repeats, and an fsck immediately after reboot will
> > > errors again. If I bring the system up in single user mode, and run fsck
> > > either before or after mounting /var, it finds no errors.
> > >
> > > I'm running 6.2_RELEASE with a custom kernel based upon generic-smp, but
> > > with a lot of unecessary bits removed, and geom_mirror compiled in. I
> > > don't think it's the drive that's at fault, all the other partitions in
> > > slice are fine, it's a fairly new drive, and it passes a self test quite
> > > happily. Included below is a transcript that attempt to show what's
> > > on in detail, is there anything else relevant?
> > >
> > > Can anyone suggest what might be going on and how to fix it, or suggest
> > > some slightly better diagnostics? Apologies if this is an RTFM issue, I
> > > have had a good dig through the handbook, but can't seem to find anything
> > > that helps.
> > Running fsck on a file system that has been mounted read/write will almost
> > always report spurious errors and can really screw up the disk if it tries
> > to 'correct' those errors.
> I'm a bit confused by this. I've been running 'fsck -n' over FreeBSD
> systems since 2.2.6, and modulo seeing the at-the-time inconsistencies
> on those filesystems in /etc/fstab that are mounted, as Chris reported
> and as are expected, I've never had a problem with it, nor seen the sort
> of inconsistent results between runs that Chris is reporting.
> > You should normally not run fsck on a mounted filesystem and you should
> > *NEVER* run fsck on a filesystem that has been mounted read/write.
> This seems to imply that using the -n switch may have different results
> than not using it and having fsck determine 'NO WRITE' itself from the
> fact that it's noticed that the fs is mounted? Are you suggesting by
> "can really screw up the disk if it tries to 'correct' those errors"
> that fsck might WRITE to a mounted fs that it's showing as 'NO WRITE'?
> I've never had any screwups with it, but then I've always specified -n.
> Later Bill Moran said:
> > Don't run fsck on mounted filesystems unless they're mounted read-only.
> > Although, it's possible I misunderstood your description of the problem.
> so I'm still curious, and am wondering if Chris using SMP kernel and/or
> geom_mirror might have anything to do with this? Or whether his use of
> 'umount -f' might be (or cause) the problem indicated by his results?
> > > # umount -f /var
> > >
> > >
> > > # mount /var
> Cheers, Ian
> email@example.com mailing list
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
If its bad to run fsck on a mounted read,write then why does
background fsck do it? or you talking about foreground fsck only?
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"