Date: Tue, 31 Jul 2001 18:01:28 +0200 From: "Karsten W. Rohrbach" <karsten@rohrbach.de> To: Alfred Perlstein <bright@mu.org> Cc: Jaye Mathisen <mrcpu@internetcds.com>, hackers@freebsd.org Subject: Re: Softupdate gripe... Message-ID: <20010731180128.H92506@mail.webmonster.de> In-Reply-To: <20010730160717.R26571@elvis.mu.org>; from bright@mu.org on Mon, Jul 30, 2001 at 04:07:17PM -0500 References: <20010730132122.C548@apocalypse.cdsnet.net> <20010730160043.Q26571@elvis.mu.org> <20010730160717.R26571@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--JI+G0+mN8WmwPnOn
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Alfred Perlstein(bright@mu.org)@2001.07.30 16:07:17 +0000:
> * Alfred Perlstein <bright@mu.org> [010730 16:01] wrote:
> [re: speeding up freeing of space when using softupdates]
> >=20
> > If you want to accellerate the release of blocks issue a couple
> > of sync(1) commands:
> >=20
> > sync;sync;sync;
> >=20
> > which will 'accelerate' the free'ing of space, actually it will=20
> > accellerate the writing of the meta data that will actually free
> > up the space.
>=20
> Let me add that this will not _really_ accelerate the process, it
> may give you instant gratification where you'll see a bunch of
> space, but by issuing a sync you're actually going to slow down
> the removal of files in the long run. Basically for speed you
> don't want to issue a sync until the rm command completes, if at
> all since the sync will also muck with other disk activity.
>=20
isn't all this behaviour controlled by vfs.ffs.doasyncfree ?
root@nGENn:defiler[/sys]28# grep -rsi doasyncfree ./ufs
=2E/ufs/ffs/ffs_alloc.c:static int doasyncfree =3D 1;
=2E/ufs/ffs/ffs_alloc.c:SYSCTL_INT(_vfs_ffs, FFS_ASYNCFREE, doasyncfree,
CTLFLAG_RW, &doasyncfree, 0, "");
=2E/ufs/ffs/ffs_alloc.c: * strict correctness, the `doasyncfree' flag
should be set to zero.
=2E/ufs/ffs/ffs_alloc.c: * The test on `doasyncfree' should be changed
to test a flag
=2E/ufs/ffs/ffs_alloc.c: if (doasyncfree)
=2E/ufs/ffs/ffs_alloc.c: if (!doasyncfree)
=2E/ufs/ffs/ffs_alloc.c: if (doasyncfree)
=2E/ufs/ffs/ffs_extern.h: { "doasyncfree", CTLTYPE_INT },
from ffs_alloc.c:
/*
* Next we must write out the modified inode and indirect blocks.
* For strict correctness, the writes should be synchronous since
* the old block values may have been written to disk. In practise
* they are almost never written, but if we are concerned about
* strict correctness, the `doasyncfree' flag should be set to zero.
*
* The test on `doasyncfree' should be changed to test a flag
* that shows whether the associated buffers and inodes have
* been written. The flag should be set when the cluster is
* started and cleared whenever the buffer or inode is flushed.
* We can then check below to see if it is set, and do the
* synchronous write only when it has been cleared.
*/
cheers,
/k
--=20
> MCSE: Minesweeper Consultant & Solitaire Engineer
KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie
http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.n=
et/
karsten&rohrbach.de -- alpha&ngenn.net -- alpha&scene.org -- catch@spam.de
GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 B=
F46
Please do not remove my address from To: and Cc: fields in mailing lists. 1=
0x
--JI+G0+mN8WmwPnOn
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: For info see http://www.gnupg.org
iD8DBQE7ZtZYM0BPTilkv0YRAgxeAJ9E/DYSrAfeaVjZGYZV2p/KZbAkZgCeI4xS
wXFAmg/7AD/hBrWwmxMAK3g=
=nFA5
-----END PGP SIGNATURE-----
--JI+G0+mN8WmwPnOn--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010731180128.H92506>