By user12625760 on Apr 01, 2005
Not when the file system is mounted!
I've been banging my head with this one of an on for a few weeks. I got an email from an engineer who was talking to a customer (who are always right) saying that when they run fsck on a live file system it would report errors:
# fsck / \*\* /dev/vx/rdsk/rootvol \*\* Currently Mounted on / \*\* Phase 1 - Check Blocks and Sizes \*\* Phase 2 - Check Pathnames \*\* Phase 3 - Check Connectivity UNREF DIRECTORY I=5522736 OWNER=root MODE=40755 SIZE=512 MTIME=Mar 31 13:07 2005 CLEAR? y \*\* Phase 4 - Check Reference Counts \*\* Phase 5 - Check Cyl groups 67265 files, 1771351 used, 68625795 free (14451 frags, 8576418 blocks, 0.0% fragmentation) \*\*\*\*\* FILE SYSTEM WAS MODIFIED \*\*\*\*\*
I kept telling them that running fsck on a live file system can and probably will generate these “errors”. The kernel's in memory copy of the file system is correct and eventually it will bring the on disk copy back in line. However by answering yes they have now corrupted the on disk copy of the file system and to make things worse the kernel does not know this so may not run fsck when the system boots. The warnings section of the fsck and fsck_ufs manual pages gives you a hint that this is a bad thing to do.
There are times when it is safe to run fsck on live file system, but they are rare and involve lockfs but before you do make sure you really understand what you are doing, my bet is that if you do know, you won't really want to.
I believe the message is now understood by all involved but I'm trying to make sure by adding it to the blog sphere.