Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 (Tek) 9/28/84 based on 9/17/84; site hammer.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxb!mhuxn!mhuxm!mhuxj!houxm!vax135!cornell!uw-beaver!tektronix!orca!hammer!steveg From: steveg@hammer.UUCP (Steve Glaser) Newsgroups: net.unix-wizards Subject: Re: 4.2 fsck and /etc/rc question Message-ID: <1120@hammer.UUCP> Date: Sat, 9-Feb-85 17:20:28 EST Article-I.D.: hammer.1120 Posted: Sat Feb 9 17:20:28 1985 Date-Received: Mon, 11-Feb-85 07:12:09 EST References: <649@turtlevax.UUCP> Reply-To: steveg@hammer.UUCP (Steve Glaser) Distribution: net Organization: Tektronix, Wilsonville OR Lines: 37 Summary: In article <649@turtlevax.UUCP> Ed(mund) Trujillo @ CADLINC, Menlo Park writes: >Why does the following scenario happen under 4.2 running on a vax 750? > >At boot time, fsck finds out that the root file system was modified so >it exits with a condition code of 4 that is passed on to /etc/rc which >immediately does an /etc/reboot -n. According to the documentation for >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? 4.2 fsck uses the cooked device on the fsck of the root filesystem. When fsck is done, if it had to modify the superblock of the filesystem there will be TWO copies of the superblock around in kernel memory. One is the copy kept by the kernel cause the file system is mounted and the other is a normal block in the block buffer cache due to the write by fsck when it fixed the superblock. The sync(2) system call will out BOTH of these copies (and always has). The trick on 4.2 (4.1 too?) is that they the kernel makes sure that the block buffer version gets written out *after* the other one. Thus the sync inside fsck is correct and gets the updated stiff onto the disk. You must then avoid all syncs until the reboot cause the copy in the block buffer cache is no longer marked dirty (cause the sync in fsck wrote it out and nobody has changed it since then). Thus another sync would write out the wrong copy of the superblock onto disk, undoing some of the work that fsck just did. Summary: this is a case where one sync (inside fsck) is correct and more than one will undo some of the work fsck just did for you. Disclaimer: I'm not saying that I *like* this scheme. It works, but seems kinda fragile. At bare minimum, it should be documented and the "new expanded" semantics of sync(2) should be guaranteed by all future systems. Steve Glaser tektronix!steveg