Re: reboot on freebsd 5.3-beta1

On 25 Aug, Jon Noack wrote:
> On 08/25/04 13:31, Don Lewis wrote:
>> On 25 Aug, bettan wrote:
>>> When i reboot , i have Syncing disk , vnodes remaining and numbers
>>> but it isn't quickly and i don't umount my files systems before the
>>> reboot.
>> 
>> It should print a number once per second.  The numbers should quickly
>> decrease to something in the low single digits. It is not unusual to see
>> the number decrease to zero and then bounce back up a couple of times.
>> Spending about 10 seconds or so at this stage is not unexpected.
> 
> This is a relatively recent change in behavior to workaround the fact 
> that IDE/ATA controllers/drives report that they have successfully 
> written data before they actually perform the write.  With the old quick 
> sync, people were experiencing corruption and data loss when rebooting. 
>   The new behavior is much more conservative and is designed to minimize 
> risk.

Before this change, the system attempted to sync all the file systems
after it disabled the syncer thread.  The problem was that if soft
updates was in use and there was a lot of file system activity shortly
before system shutdown, there could be some mutually dependent file
system writes buffered that the final sync code couldn't handle.  When
this happened, the system would get stuck at the "syncing disks, buffers
remaining..." stage and after an initial decrease, the number of buffers
would stabilize at some non-zero value.  Eventually the final sync code
would time out and shut down the system with the mounted file systems
marked unclean.  I could easily reproduce this problem by rebooting
shortly after running mergemaster, so I got in the habit of running the
sync command three times and waiting a bit before rebooting as a
workaround.

The IDE/ATA problem only happened when powering off the system.  I
*think* it might have been fixed by explicitly telling the drives to do
a cache flush.  There is also a tuneable delay
(kern.shutdown.poweroff_delay) before turning off the power to give the
drives time to flush their write caches even if they ignore any explicit
flush command.

The system shutdown delay currently observed at the "Syncing disk, vnodes
remaining" stage should be roughly the same as delay previously seen at
the "syncing disks, buffers remaining..." stage.  I've got some ideas on
how to speed it up.