Date: Fri, 23 Jun 2006 21:20:21 +0200 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: freebsd-fs@freebsd.org Subject: Re: Journaling UFS with gjournal. Message-ID: <20060623192021.GB40269@garage.freebsd.pl> In-Reply-To: <200606221500.k5MF038R074998@lurza.secnetix.de> References: <200606221500.k5MF038R074998@lurza.secnetix.de>
next in thread | previous in thread | raw e-mail | index | archive | help
--/WwmFnJnmDyWGHa4 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 22, 2006 at 05:00:03PM +0200, Oliver Fromme wrote: +> Pawel Jakub Dawidek <pjd@freebsd.org> wrote: +> > GJournal was designed to journal GEOM providers, so it actually works +> > below file system layer, but it has hooks which allow to work with +> > file systems. In other words, gjournal is not file system-depended, +> > it can work probably with any file system with minimum knowledge +> > about it. I implemented only UFS support. +>=20 +> Very cool. Thanks for providing journaling to FreeBSD. +>=20 +> How "stable" should your code be considered? I assume it +> hasn't been subject to testing by a wider audience yet, +> so it should be considered "alpha" quality, right? It works currently on about 100 heavy loaded servers in production and it works well. There is still one issue I'm trying to track down, but it is very hard to trigger. It doesn't currupt the data, but can hang the system. But. GJournal was tested only on a specific workload, so it should be considered experimental! +> First of all, is it possible to add journaling to an +> existing file system, i.e. without having to dump, newfs +> and restore? If you have an additional partition for journal you may try, but gjournal will steal the last sector from the provider holding your file system. I can't tell you it is safe or not. +> > When last +> > name is deleted, the file/directory is moved to the .deleted/ +> > directory and removed from there on last close. +>=20 +> Is that directory located in the root of the file system, +> similar to the .snap directory for snapshots? Yes. +> > [...] +> > Reading. grep -r on two src/ directories in parallel: +> > UFS: 84s +> > UFS+SU: 138s +> > gjournal(1): 102s +> > gjournal(2): 89s +> >=20 +> > As you can see, even on one disk, untaring eight src.tgz is two times +> > faster than UFS+SU. I've no idea why gjournal is faster in reading. +>=20 +> Maybe it is because of the atime updates. You'll get a lot +> of them when grepping recursively on the src tree. AFAIR file system was mounted with noatime, but I'm not sure. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --/WwmFnJnmDyWGHa4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD4DBQFEnD71ForvXbEpPzQRAj0QAJiE7eY3lcf6nA9WgryawCQfxfLQAKCheFnQ WJ2B6Me3/EG2yu5IZr4VNQ== =z0hi -----END PGP SIGNATURE----- --/WwmFnJnmDyWGHa4--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060623192021.GB40269>