Date: Thu, 22 Jun 2006 17:46:24 +0200 (CEST) From: Oliver Fromme <olli@lurza.secnetix.de> To: freebsd-fs@FreeBSD.ORG, pjd@FreeBSD.ORG Subject: Re: Journaling UFS with gjournal. Message-ID: <200606221546.k5MFkO59076905@lurza.secnetix.de> In-Reply-To: <449AB05D.3030402@centtech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Eric Anderson <anderson@centtech.com> wrote: > Oliver Fromme wrote: > > [...] > > However, if the size of the journals provider is twice the > > maximum raw transfer rate of the disk multiplied by the I should have been more specific: "of the disk containing the _journal_ provider", of course. > > switch interval time (as you recommended), it should be > > impossible to get a journal overrun. > > What if the journal had to write out little bits across the entire > journaled area, so the throughput was greatly reduced, while the > journaled area had massive heavy random reads keeping the disk heads > very busy? In that case there is even less danger of an overrun, because the many seek operations of the disk will reduce the throughput, so it will be far from reaching the end of the journal space before then end of the journal switch interval. Pawel, please correct me if I'm wrong. The maximum raw transfer rate of the journal provider is a hard limit which cannot be exceeded. If you configure the size of the journal provider to be twice that maximum rate multiplied by the switch interval, there is simply no way to hit the end of the journal space before the end of the switch interval. The worst case would happen when there have been no write operations for a while, so the journal is empty, and the inactive journal does not need to be read (i.e. the disk is idle). Now a huge amount of write operations start, causing to fill the active journal sequentially with the maximum possible throughput (almost no seek operations of the disk heads). The recommendation for the size of the journal provider should account for that worst case. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "One of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs." -- Robert Firth
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200606221546.k5MFkO59076905>