Date: Wed, 21 Sep 2011 11:41:08 +0100 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: Ross <basarevych@gmail.com> Cc: freebsd-questions@freebsd.org Subject: Re: UFS journal size Message-ID: <4E79BF44.206@infracaninophile.co.uk> In-Reply-To: <CANmv3=yuQudqqfj8xA3kQkH1XHjSBxgkR5zAB_jwpVWk9RxFeQ@mail.gmail.com> References: <CANmv3=yuQudqqfj8xA3kQkH1XHjSBxgkR5zAB_jwpVWk9RxFeQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigE675F24E571D1F9E8D92D284
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 21/09/2011 10:48, Ross wrote:
> Quoting the manpage:
>=20
> -s jsize Specifies size of the journal if only one provider i=
s
> used for both data and journal. The default is =
one
> gigabyte. Size should be chosen based on provid=
er's
> load, and not on its size; recommended minimum i=
s twice
> the size of the physical memory installed. It i=
s not
> recommended to use gjournal for small file syste=
ms
> (e.g.: only few gigabytes big).
>=20
> My question is: if I have 4 or 8 GB of RAM should I create 8 or even
> 16 GB journals?.. This seems huge especially if the fs size without
> journal is only 10 gigs. Or the recommended minimum is for systems low
> on RAM?
How much churn do you expect in the data on that partition? A journal
that's about the same size as the actual filesystem in question and on
the same physical device is not really going to get you any advantages.
If it's mostly going to be read rather than written, then you wouldn't
fill up that size of journal in any case.
The 'twice physical RAM' advice is all about achieving maximum
performance on large filesystems with lots of data writes: if write
performance is not actually a limiting factor, then you could get away
with a much smaller or even no journal at all.
You might just as well use plain UFS+Softupdates. Softupdates to
provide the meta-data ordering feature, so that if you do crash and need
to fsck the filesystem, there's not going to be any really nasty stuff
to fix. Plain UFS because a filesystem of that size will take about as
long to fsck as it would to replay all the journalled but uncommitted
updates.
Cheers,
Matthew
--=20
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
JID: matthew@infracaninophile.co.uk Kent, CT11 9PW
--------------enigE675F24E571D1F9E8D92D284
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk55v0sACgkQ8Mjk52CukIyT2QCfYOs3JLgFKSChtskTMKNoCijv
/wYAoIhh1ZrB4YNs/OjbDKvpzI7NMeqF
=VT/b
-----END PGP SIGNATURE-----
--------------enigE675F24E571D1F9E8D92D284--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E79BF44.206>