Date: Mon, 22 Jul 2002 18:24:52 -0400 From: "Brian T. Schellenberger" <bts@babbleon.org> To: Kirk McKusick <mckusick@beastie.mckusick.com> Cc: Julian Elischer <julian@elischer.org>, Ronald Klop <ronald@not4mail.cs.vu.nl>, stable@FreeBSD.ORG, David Malone <dwmalone@maths.tcd.ie> Subject: Re: softupdates: any way to force sync? Message-ID: <200207221824.52197.bts@babbleon.org> In-Reply-To: <200207221658.g6MGw059025808@beastie.mckusick.com> References: <200207221658.g6MGw059025808@beastie.mckusick.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Will remounting read-only also force a full sync?
On Monday 22 July 2002 12:58 pm, Kirk McKusick wrote:
| The -current system has changes that force a sync if you are about
| to run out of space with soft dependencies pending. So, in that
| system you will not get the false out-of-space condition. Unfortunately
| the changes are rather wide ranging and not really suitable for MFC
| (or perhaps I should say, I am not willing to make the MFC, though
| I would review such a change if someone wanted to try and pull it
| together).
|
| For -stable, you can do one of two things to force a sync.
| The first is to either add a flag to the existing sync() call or
| add a new system call that works exactly like the existing sync()
| call except that it needs to call VFS_SYNC with the MNT_WAIT flag
| instead of the MNT_NOWAIT flag. That way VFS_SYNC will not return
| until all the data is sync'ed to disk (which may be forever if
| there is more disk requests being generated per second than the
| bandwidth of the disk can support). The other choice is to attempt
| to unmount the filesystem in question (as root of course). As part
| of trying to do the unmount, the kernel will flush all the vnodes
| associated with the filesystem. As long as there is at least one
| active vnode on the filesystem (for example you can chdir into the
| filesystem before attempting the unmount), the unmount will fail
| with `filesystem busy', but you will have achieved the desired sync
| operation.
|
| Kirk McKusick
|
| =-=-=-=-=-=
|
| From: "Brian T. Schellenberger" <bts@babbleon.org>
| To: Julian Elischer <julian@elischer.org>,
| Ronald Klop <ronald@not4mail.cs.vu.nl>, mckusick@mckusick.com
| Subject: Re: softupdates: any way to force sync?
| Date: Sun, 21 Jul 2002 11:38:14 -0400
| Cc: stable@FreeBSD.ORG, David Malone <dwmalone@maths.tcd.ie>
| X-ASK-Info: Confirmed by User
|
| [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?200207221824.52197.bts>