fsck to fix HD problem

[Ian Smith]

On Wed, 25 Jul 2007 07:27:27 +0200
 Zbigniew Szalbot <zbigniew at szalbot.homedns.org> wrote:

 > I got a Charlie report:
 > +WARNING: / was not properly dismounted 
 > +WARNING: /var was not properly dismounted 
 > +/var: mount pending error: blocks 8200 files 43 
 > +/usr: mount pending error: blocks 4552 files 6

'mount pending error' is what you get as background fsck gets busy with
cleaning up filesystems improperly dismounted, ie dirty.  If you check
/var/log/messages for after that boot you'll likely see 'DEFER' messages
then background fsck listing any corrections and finishing, probably ok.

 > so I decided to use fsck to check my HD. I ran it
 > in the foreground mode with the -y flag. It gives me the below
 > information. My question is - should I worry (it is more a home machine
 > than a real server) and if yes, how can I fix the problem?

If you'd shown the lines just before what you pasted, they probably
would have looked like, apart from your slice numbering: 

  ** /dev/ad0s2d (NO WRITE)
  ** Last Mounted on /var
  ** Phase 1 - Check Blocks and Sizes
  ** Phase 2 - Check Pathnames
  ** Phase 3 - Check Connectivity

Notice (NO WRITE).  As others pointed out, fsck won't write to a mounted
filesystem; running 'fsck -y /var' is then the same as 'fsck -n /var'

You can run 'fsck -n' anytime you like, even as a non-root user, and see
what would show up if you (again) lost power right now without a clean
shutdown.  Here's the rest of mine, run just now .. pretty similar to
yours below, noting that the file mtimes are as of my last boot .. 

  ** Phase 4 - Check Reference Counts
  UNREF FILE I=18  OWNER=mysql MODE=100600
  SIZE=0 MTIME=Jul  3 23:28 2007
  CLEAR? no

  UNREF FILE I=24  OWNER=mysql MODE=100600
  SIZE=0 MTIME=Jul  3 23:28 2007
  CLEAR? no

  UNREF FILE I=39  OWNER=mysql MODE=100600
  SIZE=0 MTIME=Jul  3 23:28 2007
  CLEAR? no

  UNREF FILE I=25246  OWNER=root MODE=140666
  SIZE=0 MTIME=Jul  3 23:28 2007
  CLEAR? no

  ** Phase 5 - Check Cyl groups
  SUMMARY BLK COUNT(S) WRONG IN SUPERBLK
  SALVAGE? no

  2347 files, 56617 used, 70481 free (609 frags, 8734 blocks, 0.5%  fragmentation)

 > ** Phase 4 - Check Reference Counts
 > UNREF FILE I=133267  OWNER=root MODE=140666
 > SIZE=0 MTIME=Jul 24 07:54 2007
 > CLEAR? no
 > 
 > UNREF FILE I=235892  OWNER=mysql MODE=100600
 > SIZE=0 MTIME=Jul 24 16:43 2007
 > CLEAR? no
 > 
 > UNREF FILE I=235894  OWNER=mysql MODE=100600
 > SIZE=0 MTIME=Jul 24 16:43 2007
 > CLEAR? no
 > 
 > UNREF FILE I=235929  OWNER=mysql MODE=100600
 > SIZE=0 MTIME=Jul 24 16:43 2007
 > CLEAR? no
 > 
 > UNREF FILE I=235932  OWNER=mysql MODE=100600
 > SIZE=0 MTIME=Jul 24 16:43 2007
 > CLEAR? no
 > 
 > UNREF FILE I=235933  OWNER=mysql MODE=100600
 > SIZE=0 MTIME=Jul 24 16:43 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
 > 
 > 53119 files, 473457 used, 617845 free (10557 frags, 75911 blocks, 1.0%
 > fragmentation)

If in doubt, drop to single user, umount /var and fsck it .. but you're
probably in good shape; the sort of inconsistencies shown above are to
be entirely expected whenever running fsck (-n) on a mounted fs. 

Cheers, Ian