If you have softupdates enabled and write a large file, it's possible when you shutdown the machine, that syncing gives up before all buffers are written: syncing ... 15 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 giving up Fix: - replace the 20 iterations in syncing by a sysctl variable - find a better algorithm for syncing How-To-Repeat: Write a large file and reboot imediately. This error may not occur if your harddisk is fast enough
Christian Schade wrote: > My workaround is still to have a "sync" and "sleep 30" in /etc/rc.shutdown. Hmm, I tried it by placing sync and sleep 30 at the end of rc.shutdown, and it doesn't solve my A7V's shutdown problem. I get something like 10 5 1 1 1 1 1 1...for its full 20 iterations. The sleep 30 is working because I don't get the syncing disks message later on, but the sync command activates my disk for a brief period of time. I noticed I'm experiencing this problem quite often--7 out of 10 reboots/shutdowns--after I've added a TDK 12/10/32 ATAPI CDRW to my system. Primary IDE - Seagate as Master, Maxtor as secondary Secondary IDE - Pioneer DVD as Master, TDK CDRW as secondary Promise primary IDE - none Promise secondary IDE - none Ken
Hmm... Maybe this problem could be related to the disk's write cache. Some disks delay the writes to media indefinitely. Suggestion: upgrade to 4.3-RELEASE or 4-STABLE (WC is now disabled by default and there are tunables for enabling it) and see if the problem persists. -- JMA ****** Jose M. Alcaide // jose@we.lc.ehu.es // jmas@FreeBSD.org ****** ** "Beware of Programmers who carry screwdrivers" -- Leonard Brandwein **
I've tried using FreeBSD 4.3-STABLE and the problem still persists. sysctl says that hw.ata.wc is 0. Ken
I have found that rather than doing a "shutdown -p 0" or "reboot" from multiuser mode, but instead if I bring the box to single-user mode via "shutdown now" then followed by a "reboot"/"shutdown -p 0", then the problem goes away or isn't as prone to not sync properly. Ken
State Changed From-To: open->feedback Does this problem still occur?
Adding to the audit trail. In message <20011119153902.A80069@cube.sax.de>, Christian Schade writes: >iedowse@FreeBSD.org (iedowse@FreeBSD.org) wrote: >> Synopsis: syncing on shutdown leaves filesystem dirty >> >> State-Changed-From-To: open->feedback >> State-Changed-By: iedowse >> State-Changed-When: Sun Nov 18 11:53:05 PST 2001 >> State-Changed-Why: >> >> Does this problem still occur? >> >> http://www.FreeBSD.org/cgi/query-pr.cgi?pr=24085 > >Yes, the problem still occurs. :( > >Meanwhile I'm using 4.4-stable, but last week the filesytem was dirty >after reboot. I modified my /etc/rc.shutdown to wait 30 seconds after >doing a sync to give the system enought time to write open files back. >It seem to reduce the problem, but last week it didn't help. >I have a 40GB disk and it takes about 5 minutes to fsck. :( > >Sincerly, >Christian Schade
State Changed From-To: feedback->open Feedback has been requested and received; throw this PR back open.
State Changed From-To: open->feedback hello, is this problem still relevant for recent freebsd versions like 6.x?
Responsible Changed From-To: freebsd-bugs->remko grab the pr.
State Changed From-To: feedback->closed feedback timeout