Date: Sun, 21 Jul 2002 11:38:14 -0400 From: "Brian T. Schellenberger" <bts@babbleon.org> To: Julian Elischer <julian@elischer.org>, Ronald Klop <ronald@not4mail.cs.vu.nl>, mckusick@mckusick.com Cc: stable@FreeBSD.ORG, David Malone <dwmalone@maths.tcd.ie> Subject: Re: softupdates: any way to force sync? Message-ID: <200207211138.14607.bts@babbleon.org> In-Reply-To: <Pine.BSF.4.21.0207181205540.84569-100000@InterJet.elischer.org> References: <Pine.BSF.4.21.0207181205540.84569-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200207211138.14607.bts>