Re: fsck strangeness
Ian Smith wrote: On Wed, 22 Aug 2007, Chris wrote: 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? Well I was referring to foreground fsck, and I still don't know why running it on a mounted fs is 'bad' when fsck runs in 'NO WRITE' mode anyway when it finds a fs is mounted, hence my query above. Here's my understanding: Mounted fs (rw) isn't in stable state, there may be some writes to it - daemons, buffers flushes, etc. In this condition fsck can report inconsistency. And fsck running in 'NO WRITE' won't help anyway :) Cheers, Karol -- Karol Kwiatkowski karol.kwiat at gmail dot com OpenPGP 0x06E09309 signature.asc Description: OpenPGP digital signature
Re: fsck strangeness
On Thu, 23 Aug 2007, Karol Kwiatkowski wrote: Ian Smith wrote: On Wed, 22 Aug 2007, Chris wrote: 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? Well I was referring to foreground fsck, and I still don't know why running it on a mounted fs is 'bad' when fsck runs in 'NO WRITE' mode anyway when it finds a fs is mounted, hence my query above. Here's my understanding: Mounted fs (rw) isn't in stable state, there may be some writes to it - daemons, buffers flushes, etc. In this condition fsck can report inconsistency. And fsck running in 'NO WRITE' won't help anyway :) a) Absolutely. b) Indeed it usually does, fairly consistently, especially on /var. c) No it won't help (except where it can help locate problems in a real mess like bad blocks), but the assertion in question was, can it hurt? Cheers, Ian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fsck strangeness
Ian Smith wrote: On Thu, 23 Aug 2007, Karol Kwiatkowski wrote: Ian Smith wrote: On Wed, 22 Aug 2007, Chris wrote: 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? Well I was referring to foreground fsck, and I still don't know why running it on a mounted fs is 'bad' when fsck runs in 'NO WRITE' mode anyway when it finds a fs is mounted, hence my query above. Here's my understanding: Mounted fs (rw) isn't in stable state, there may be some writes to it - daemons, buffers flushes, etc. In this condition fsck can report inconsistency. And fsck running in 'NO WRITE' won't help anyway :) a) Absolutely. b) Indeed it usually does, fairly consistently, especially on /var. c) No it won't help (except where it can help locate problems in a real mess like bad blocks), but the assertion in question was, can it hurt? Ah sorry, I missed that. With 'NO WRITE' one can suppose it shouldn't hurt anything except performance ;) I made a quick scan through the source and it looks like it won't: - in src/sbin/fsck_ffs/setup.c if fs is mounted rw fswritefd is set to -1 - in src/sbin/fsck_ffs/fsutil.c blwrite(), flush() and ckfini() won't write anything if fswritefd0 Unless, of course, I'm missing something. Cheers, Karol -- Karol Kwiatkowski karol.kwiat at gmail dot com OpenPGP 0x06E09309 signature.asc Description: OpenPGP digital signature
Re: fsck strangeness
On Thu, 23 Aug 2007, Karol Kwiatkowski wrote:
Ian Smith wrote:
On Thu, 23 Aug 2007, Karol Kwiatkowski wrote:
Ian Smith wrote:
On Wed, 22 Aug 2007, Chris wrote:
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?
Well I was referring to foreground fsck, and I still don't know why
running it on a mounted fs is 'bad' when fsck runs in 'NO WRITE' mode
anyway when it finds a fs is mounted, hence my query above.
Here's my understanding:
Mounted fs (rw) isn't in stable state, there may be some writes to it -
daemons, buffers flushes, etc. In this condition fsck can report
inconsistency. And fsck running in 'NO WRITE' won't help anyway :)
a) Absolutely.
b) Indeed it usually does, fairly consistently, especially on /var.
c) No it won't help (except where it can help locate problems in a real
mess like bad blocks), but the assertion in question was, can it hurt?
Ah sorry, I missed that. With 'NO WRITE' one can suppose it shouldn't
hurt anything except performance ;)
I made a quick scan through the source and it looks like it won't:
- in src/sbin/fsck_ffs/setup.c
if fs is mounted rw fswritefd is set to -1
Ah, the source, who would have thought .. so it does ..
if (bkgrdflag == 0
(nflag || (fswritefd = open(dev, O_WRONLY)) 0)) {
fswritefd = -1;
if (preen)
pfatal(NO WRITE ACCESS);
printf( (NO WRITE));
}
.. which explore answered the flip side of my query, I think: fsck (in
fg mode) _will_ update an fs mounted readonly, unless -n is specified.
- in src/sbin/fsck_ffs/fsutil.c
blwrite(), flush() and ckfini() won't write anything if fswritefd0
Unless, of course, I'm missing something.
I'll keep using -n to be sure for 'casual' fsck, never failed me, and
one day I may figure out how bg fsck works. Thanks for the tute :)
Cheers, Ian
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fsck strangeness
Ian Smith wrote: My knowledge of this is thin, despite reading McKusick's paper through several times, but we're told that background fsck runs on a snapshot of the fs concerned. How any bg fsck corrections are woven back into the live fs later is still a mystery to me, but that's because I still have an only barely superficial understanding of how snapshots work .. Background FSCK only repairs a small subset of filesystem incosistencies. Specifically, those inconsistencies that softupdates allows to occur, such as data blocks allocated out of the bitmap, but not actually assigned to any inode. Background FSCK only needs to find these (by looking at a fully consistent and unchanging snapshot of the filesystem) and deallocate them in the live filesystem, a simple operation given that it's guaranteed nothing will be using a block that is both marked used and not assigned to anything. -- Fuzzy love, -CyberLeo Technical Administrator CyberLeo.Net Webhosting http://www.CyberLeo.Net [EMAIL PROTECTED] Furry Peace! - http://.fur.com/peace/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fsck strangeness
On Thu, 23 Aug 2007, CyberLeo Kitsana wrote: Ian Smith wrote: My knowledge of this is thin, despite reading McKusick's paper through several times, but we're told that background fsck runs on a snapshot of the fs concerned. How any bg fsck corrections are woven back into the live fs later is still a mystery to me, but that's because I still have an only barely superficial understanding of how snapshots work .. Background FSCK only repairs a small subset of filesystem incosistencies. Specifically, those inconsistencies that softupdates allows to occur, such as data blocks allocated out of the bitmap, but not actually assigned to any inode. Background FSCK only needs to find these (by looking at a fully consistent and unchanging snapshot of the filesystem) and deallocate them in the live filesystem, a simple operation given that it's guaranteed nothing will be using a block that is both marked used and not assigned to anything. Thanks for that nutshell, CL. Sometimes little bits help the most ^}= ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fsck strangeness
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, but subsequently running an fsck on /dev/ad8s1e (mounted as /var) detects errors. Even if this first check is run whilst the file system is mounted, 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 find 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 the 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 going 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 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions 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? Chris ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fsck strangeness
On Wed, 22 Aug 2007, Chris wrote: 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, but subsequently running an fsck on /dev/ad8s1e (mounted as /var) detects errors. Even if this first check is run whilst the file system is mounted, 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 find 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 the 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 going 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 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? Well I was referring to foreground fsck, and I still don't know why running it on a mounted fs is 'bad' when fsck runs in 'NO WRITE' mode anyway when it finds a fs is mounted, hence my query above. My knowledge of this is thin, despite reading McKusick's paper through several times, but we're told that background fsck runs on a snapshot of the fs concerned. How any bg fsck corrections are woven back into the live fs later is still a mystery to me, but that's because I still have an only barely superficial understanding of how snapshots work .. I still feel that your 'umount -f /var' seems potentially hairy, but can't say if that might explain the behaviour you were reporting. Cheers, Ian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fsck strangeness
On 18/08/07, Christopher Key [EMAIL PROTECTED] 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, but subsequently running an fsck on /dev/ad8s1e (mounted as /var) detects errors. Maybe fsck should be rewritten to give sudo-style insults if you try to run it on a live filesystem. -- -- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fsck strangeness
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, but subsequently running an fsck on /dev/ad8s1e (mounted as /var) detects errors. Even if this first check is run whilst the file system is mounted, 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 find 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 the 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 going 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 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
fsck strangeness
Hello, I'm having some rather strange behaviour with fsck. When I boot the system, it asserts that all the file systems are clean, but subsequently running an fsck on /dev/ad8s1e (mounted as /var) detects errors. Even if this first check is run whilst the file system is mounted, 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 find 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 the 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 going 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. Regards, Chris # fsck /dev/ad8s1e ** /dev/ad8s1e (NO WRITE) ** Last Mounted on /var ** Phase 1 - Check Blocks and Sizes INCORRECT BLOCK COUNT I=706567 (4 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=706583 (4 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=706593 (80 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=706594 (80 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=706595 (4 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=706598 (4 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=730708 (4 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=730779 (4 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=730780 (4 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=730781 (4 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=730784 (4 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=730799 (4 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=730819 (24 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=1036295 (4 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=1036313 (48 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=1036314 (4 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=1036315 (4 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=1036317 (4 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=1036320 (4 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=1036321 (4 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=1036323 (4 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=1036324 (4 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=1719339 (12 should be 8) CORRECT? no INCORRECT BLOCK COUNT I=1742856 (4 should be 0) CORRECT? no ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts UNREF FILE I=730782 OWNER=slimserv MODE=100644 SIZE=771 MTIME=Aug 18 16:27 2007 RECONNECT? no CLEAR? no UNREF FILE I=730783 OWNER=slimserv MODE=100644 SIZE=1309 MTIME=Aug 18 16:27 2007 RECONNECT? no CLEAR? no UNREF FILE I=730818 OWNER=slimserv MODE=100644 SIZE=10825 MTIME=Aug 18 16:27 2007 RECONNECT? no CLEAR? no UNREF FILE I=2049026 OWNER=slimserv MODE=100600 SIZE=0 MTIME=Aug 18 16:40 2007 CLEAR? no UNREF FILE I=2049029 OWNER=slimserv MODE=100600 SIZE=0 MTIME=Aug 18 16:40 2007 CLEAR? no UNREF FILE I=2049030 OWNER=slimserv MODE=100600 SIZE=0 MTIME=Aug 18 16:40 2007 CLEAR? no UNREF FILE I=2049031 OWNER=slimserv MODE=100600 SIZE=0 MTIME=Aug 18 16:40 2007 CLEAR? no UNREF FILE I=2049032 OWNER=slimserv MODE=100600 SIZE=0 MTIME=Aug 18 16:40 2007 CLEAR? no ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? no SUMMARY INFORMATION BAD SALVAGE? no BLK(S) MISSING IN BIT MAPS SALVAGE? no 1048 files, 53949 used, 8068123 free (643 frags, 1008435 blocks, 0.0% fragmentation) # fsck /dev/ad8s1e ** /dev/ad8s1e (NO WRITE) ** Last Mounted on /var ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts UNREF FILE I=2049026 OWNER=slimserv MODE=100600 SIZE=0 MTIME=Aug 18 16:40 2007 CLEAR? no UNREF FILE I=2049029 OWNER=slimserv MODE=100600 SIZE=0 MTIME=Aug 18 16:40 2007 CLEAR? no UNREF FILE I=2049030 OWNER=slimserv MODE=100600 SIZE=0 MTIME=Aug 18 16:40 2007 CLEAR? no UNREF FILE I=2049031 OWNER=slimserv MODE=100600 SIZE=0 MTIME=Aug 18 16:40 2007 CLEAR? no UNREF FILE I=2049032 OWNER=slimserv MODE=100600 SIZE=0 MTIME=Aug 18 16:40 2007 CLEAR? no ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? no SUMMARY INFORMATION BAD SALVAGE? no BLK(S) MISSING IN BIT MAPS SALVAGE? no 1045 files, 54019 used, 8068133 free (653 frags, 1008435 blocks, 0.0% fragmentation) # fsck
Re: fsck strangeness
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, but subsequently running an fsck on /dev/ad8s1e (mounted as /var) detects errors. Even if this first check is run whilst the file system is mounted, 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 find 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 the 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 going 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. 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. -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fsck strangeness
Christopher Key [EMAIL PROTECTED] 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, but subsequently running an fsck on /dev/ad8s1e (mounted as /var) detects errors. Even if this first check is run whilst the file system is mounted, 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 find 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. Don't run fsck on mounted filesystems unless they're mounted read-only. Although, it's possible I misunderstood your description of the problem. 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 the 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 going 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. Regards, Chris # fsck /dev/ad8s1e ** /dev/ad8s1e (NO WRITE) ** Last Mounted on /var ** Phase 1 - Check Blocks and Sizes INCORRECT BLOCK COUNT I=706567 (4 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=706583 (4 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=706593 (80 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=706594 (80 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=706595 (4 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=706598 (4 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=730708 (4 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=730779 (4 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=730780 (4 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=730781 (4 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=730784 (4 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=730799 (4 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=730819 (24 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=1036295 (4 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=1036313 (48 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=1036314 (4 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=1036315 (4 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=1036317 (4 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=1036320 (4 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=1036321 (4 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=1036323 (4 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=1036324 (4 should be 0) CORRECT? no INCORRECT BLOCK COUNT I=1719339 (12 should be 8) CORRECT? no INCORRECT BLOCK COUNT I=1742856 (4 should be 0) CORRECT? no ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts UNREF FILE I=730782 OWNER=slimserv MODE=100644 SIZE=771 MTIME=Aug 18 16:27 2007 RECONNECT? no CLEAR? no UNREF FILE I=730783 OWNER=slimserv MODE=100644 SIZE=1309 MTIME=Aug 18 16:27 2007 RECONNECT? no CLEAR? no UNREF FILE I=730818 OWNER=slimserv MODE=100644 SIZE=10825 MTIME=Aug 18 16:27 2007 RECONNECT? no CLEAR? no UNREF FILE I=2049026 OWNER=slimserv MODE=100600 SIZE=0 MTIME=Aug 18 16:40 2007 CLEAR? no UNREF FILE I=2049029 OWNER=slimserv MODE=100600 SIZE=0 MTIME=Aug 18 16:40 2007 CLEAR? no UNREF FILE I=2049030 OWNER=slimserv MODE=100600 SIZE=0 MTIME=Aug 18 16:40 2007 CLEAR? no UNREF FILE I=2049031 OWNER=slimserv MODE=100600 SIZE=0 MTIME=Aug 18 16:40 2007 CLEAR? no UNREF FILE I=2049032 OWNER=slimserv MODE=100600 SIZE=0 MTIME=Aug 18 16:40 2007 CLEAR? no ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? no SUMMARY INFORMATION BAD SALVAGE? no BLK(S) MISSING IN BIT MAPS SALVAGE? no 1048 files, 53949 used, 8068123 free (643 frags, 1008435 blocks, 0.0% fragmentation) # fsck /dev/ad8s1e ** /dev/ad8s1e (NO WRITE) ** Last Mounted on /var ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts UNREF FILE I=2049026 OWNER=slimserv MODE=100600 SIZE=0 MTIME=Aug 18 16:40 2007 CLEAR? no UNREF FILE I=2049029 OWNER=slimserv MODE=100600 SIZE=0 MTIME=Aug 18 16:40 2007 CLEAR? no UNREF FILE I=2049030 OWNER=slimserv MODE=100600 SIZE=0 MTIME=Aug 18 16:40 2007 CLEAR? no UNREF FILE I=2049031 OWNER=slimserv MODE=100600 SIZE=0 MTIME=Aug 18
Re: fsck strangeness
Bill Moran wrote: Christopher Key [EMAIL PROTECTED] 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, but subsequently running an fsck on /dev/ad8s1e (mounted as /var) detects errors. Even if this first check is run whilst the file system is mounted, 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 find 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. Don't run fsck on mounted filesystems unless they're mounted read-only. Although, it's possible I misunderstood your description of the problem. Thanks Eric, Bill, I must have misunderstood, I was under the impression that running fsck on a device with a mounted file system would scan, but not actaully write anything, hence its reporting 'NO WRITE'. I'll reread the fsck manpage. Is running fsck -B /dev/ad8s1e safe, as I understand it, this creates a snapshot of the filesystem and scans that. Regards, Chris ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
