Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 beta 3/9/83; site callan.UUCP
Path: utzoo!utcs!lsuc!pesnta!pertec!scgvaxd!wlbr!callan!tim
From: tim@callan.UUCP (Tim Smith)
Newsgroups: net.unix-wizards
Subject: Re: 4.2 fsck and /etc/rc question
Message-ID: <303@callan.UUCP>
Date: Fri, 8-Feb-85 16:55:29 EST
Article-I.D.: callan.303
Posted: Fri Feb  8 16:55:29 1985
Date-Received: Thu, 14-Feb-85 21:12:08 EST
References: <649@turtlevax.UUCP>
Reply-To: tim@callan.UUCP (Tim Smith)
Distribution: net
Organization: Callan Data Systems, Westlake Village, CA
Lines: 23
Summary: 

In article <649@turtlevax.UUCP> edmund@turtlevax.UUCP (Ed Trujillo) writes:
>reboot the -n option avoids the sync.  Why then does fsck do a sync() 
>before the call to exit(4) ???  Is there a logical reason for this?

The above is for 4.2bsd, so what I say may be wrong.  On Sys V it goes
like this....

When fsck is run on the root, the cooked file system is used.  This is
because of the way fsck determines when it is doing root.  So fsck must
do a sync() at the end to make sure the disk gets changed.

This can cause problems.  If there is a problem with the inode for the
console, fsck will fix it on the disk, but since it is using the console,
the modify time on the in-core copy of the inode gets changed, and so
the final sync() writes it out, putting you right back where you started!

Here at Callan, we changed fsck to NOT do the final sync when doing a
raw device.  Then problems like the above can be fixed by using fsck
on the raw root.
-- 
Duty Now for the Future
					Tim Smith
			ihnp4!wlbr!callan!tim or ihnp4!cithep!tim