From owner-freebsd-stable Sun Jul 21 9:42:28 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07A1437B400 for ; Sun, 21 Jul 2002 09:42:19 -0700 (PDT) Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DE5143E31 for ; Sun, 21 Jul 2002 09:42:18 -0700 (PDT) (envelope-from bts@fake.com) Received: from this.is.fake.com ([66.26.254.93]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Sun, 21 Jul 2002 11:38:22 -0400 Received: by this.is.fake.com (Postfix, from userid 111) id 14F69BB34; Sun, 21 Jul 2002 11:38:15 -0400 (EDT) Content-Type: text/plain; charset="iso-8859-1" From: "Brian T. Schellenberger" To: Julian Elischer , Ronald Klop , mckusick@mckusick.com Subject: Re: softupdates: any way to force sync? Date: Sun, 21 Jul 2002 11:38:14 -0400 User-Agent: KMail/1.4.2 Cc: stable@FreeBSD.ORG, David Malone References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200207211138.14607.bts@babbleon.org> Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [Mr. McKusick-- Sorry for including you mid-discussion. I initially failed to notice who had done what and included Julian rather than you.] | > Brian T.Schellenberger wrote: | | [...] | | > > What I'd like is a command like "syncupdates" or something that would | > > synchronosly force all the pending softupdates updates to update and | > > return only when that was complete. Then when I had the (rare) | > > occaisons where I really wanted them synced up, they could be synched | > > up but the rest of the time I could still let it update when it | > > pleased. | > > | > > Questions: | > > | > > - Is there any functionality already in the system that I don't know | > > about? - Are there any plans to add it? | > > | > > - If not, I might have a go at it myself. Other than your code and the | > > original paper are there any references or information that I should | > > have in hand? | > > - And would you, Julian, be willing to review whatever I might come up | > > with and possibly commit it if it looks plausible? (I don't run | > > current so whatever patches I'd come up with would be against -stable, | > > but I presume that doing a sort of "reverse MFC" to translate them to | > > -current patches wouldn't be terribly difficult.) | | I think there are much better people to review it than me.. | I have not looked at the soft updates code for 3 years :-( | Don't forget that while I commited it, I was only acting as an assitant | to Kirk. I did most of the 'mecahnical' porting parts but he | has moved a long way since then. (particularly in -current). Sorry, I hadn't realized that. I checked the README instead of the .c file for the e-mail address and grabbed it from there. I'm adding Kirk in now that I've got that straight. On Thursday 18 July 2002 03:23 pm, Julian Elischer wrote: | On Thu, 18 Jul 2002, Ronald Klop wrote: | > The following sysctl's define the delay before things are written to | > disk with softupdates. I think they work in realtime and setting them to | > 3,2,1 for a little time wil sync the disk faster. But wil make the | > caching less efficient. So play with it for a while. | > | > kern.filedelay: 30 | > kern.dirdelay: 29 | > kern.metadelay: 28 I haven't played with these, and perhaps I will, but it doesn't really address my concern, which is that 99% of the time I want it work just as it does now--but every now and again there are special cirsumstances where I want to get the disk space back right away, usually when I'm deleting gigabytes of space at one fell swoop, and I can actually wind up filling the space (over the internet sometimes!) faster than softupdates can clear it. | When we were porting Soft Updates, Kirk suggested that a sequence of | 4 syncs should be sufficient to force a full update. | e.g. sync;sleep 1;sync;sleep 1;sync;sleep 1;sync Alas, I've tried this, and it's not so. In fact I did 5 syncs (back-to-back), then I did 5 more (with sleeps in between), and it *still* didn't fully sync. It *does* seem to speed up the process quite a bit but it still doesn't guarantee synchronicity. I'm sure that umount would but that seems a little drastic, and I have to undo all my "cd"s and such to do it. | I have my suspicions that it may be possible under some situations | for some interdependencies to last longer, but I also am willing to | believe that probably Kirk was right :-) I'm afraid that your suspicious side has got the advantage over your believing side on this one. | He also said that an 'fsync()' on a file will recurse all the way to | the root of the filesystem, resolving all unsatisfied dependencies on the | way. You may want to consider this if you have a specific need. My typical need is for getting the space back. Are you suggesting that fsync()ing any file will sync up the entire file system, or just the directories and inodes that it has touch on the way to get to that file? David Malone wrote: | The problem where a disk seems to be full because of pending softupdates | changes has been fixed in -current, but I don't think the fix has | been brought into -stable yet. Well, that is my primary concern, though it's nice sometimes to know when "df" can tell me true, but write failures due to a bogus "disk full" condition is my main problem. After quite some time, I synced up to stable as of Friday, so it's possible that this will have already taken care of itself for me (I probably won't know for a while, it's only a "once every few weeks" event where this normally comes up. If not, though, I'd love to see this MFC'ed sooner rather than later and if there's anything I could do to help please let me know. -- Brian, the man from Babble-On . . . . bts@babbleon.org (personal) http://www.babbleon.org http://www.eff.org http://www.programming-freedom.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message