From owner-freebsd-mobile@FreeBSD.ORG Tue May 27 14:19:15 2003 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1340737B404 for ; Tue, 27 May 2003 14:19:15 -0700 (PDT) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id F164443F75 for ; Tue, 27 May 2003 14:19:13 -0700 (PDT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP id MUA74016; Tue, 27 May 2003 14:19:12 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 751165D04; Tue, 27 May 2003 14:19:12 -0700 (PDT) To: Michael Collette In-Reply-To: Message from Michael Collette of "Tue, 27 May 2003 12:35:06 PDT." <200305271235.06569.metrol@metrol.net> Date: Tue, 27 May 2003 14:19:12 -0700 From: "Kevin Oberman" Message-Id: <20030527211912.751165D04@ptavv.es.net> cc: FreeBSD Mailing Lists Subject: Re: When do files syncronize? X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2003 21:19:15 -0000 > From: Michael Collette > Date: Tue, 27 May 2003 12:35:06 -0700 > Sender: owner-freebsd-mobile@freebsd.org > > Here on this Thinkpad T23 I normally just Fn-F4 to put it to sleep when moving > it from work to home. This had been working pretty well, with an occasional > lock up still happening. That much is a pretty well known problem. > > This last Friday I did the usual Fn-F4 and brought my lappy on home. What I > didn't do was plug it back in until late Sunday. Bad move, as my battery is > starting to get on the weak side here. Sure enough, lost power while it was > in sleep mode. > > Powering back up the system went through the usual post-crash fsck. > Everything looked cool until I started up KMail. Lost the entirety of my > mail settings, which were anything but trivial. I wrote up a pretty bitter > bug report over on KDE's site. I really wasn't in a good mood when this > happened. > > http://bugs.kde.org/show_bug.cgi?id=58954 > > I then mentioned this problem on the KDE-FreeBSD mailing list. I got some > advice there to turn off all write cacheing via loader.conf. Now that's > done, my system seems to be a little bogged, but not too horribly bad. > > With my sob story out of the way, here's my questions... > > When this here Thinkpad goes into a sleep mode, is there any chit chat with > the OS to be sure and syncronize any outstanding writes? > > Would it be wiser to initiate going into sleep via software, such as KDE's > laptop app or some other method? Is there any difference? > > Is there some way to force outstanding writes to clear their buffers before I > put this box into sleep mode? > > > At some point I'd like to turn on write cacheing again. I REALLY don't feel > comfortable about it at this time though. Is there some way to get a feeling > of comfort back with this feature? You now know exactly why there is a strong recommendation that write cache be disabled on boxes that are subject to power failure. Files are synced just fine, but that only gets updates to the write cache. There is no way of being sure just when the data will actually get written to the disk and, if the system loses power, the answer is never. This also screws up write ordering needed by soft updates to make sure that the metadata stays consistent. You case is a "worst case" in that you had probably just updated this file and the metadata for it was still queued up. You sent it off to sleep, which spin down the disk. Since the metadata was never updated, the file ceased to exist (even though all of the data had probably made it to the disk). The cost of turning off write cache is high. I have demonstrated a factor of 8 slow-down for dd with write cache disabled. A possible alternative is to make sure that you wait a minute after terminating use of the system before suspending, Another is to do a hibernate instead of a suspend. This will write all of you memory to disk before turning off. (This also cuts battery use as the system is REALLY off when you hibernate.) You will need to create a hibernation slice on your hard disk to do this. A utility to create it is available from the IBM web site. http://www.pc.ibm.com/qtechinfo/MIGR-4PESMK.html R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634