Date: Mon, 19 Jun 2006 17:11:53 +0200 (CEST) From: Oliver Fromme <olli@lurza.secnetix.de> To: freebsd-fs@FreeBSD.ORG Subject: Re: Journaling UFS with gjournal. Message-ID: <200606191511.k5JFBrnY017899@lurza.secnetix.de> In-Reply-To: <freebsd-fs.20060619131101.GD1130@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Very cool. Thanks for providing journaling to FreeBSD. 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? I have a few questions ... First of all, is it possible to add journaling to an existing file system, i.e. without having to dump, newfs and restore? > How it works (in short). You may define one or two providers which > gjournal will use. If one provider is given, it will be used for both - > data and journal. If two providers are given, one will be used for data > and one for journal. In the case of only one provider given, how is the size of the journal specified? > When last > name is deleted, the file/directory is moved to the .deleted/ > directory and removed from there on last close. Is that directory located in the root of the file system, similar to the .snap directory for snapshots? (It reminds me of the similar case when files are deleted from an NFS server. If they're still held open by processes, they get renamed to .nfsXXXX within the original directory. I wish they would be moved into a fixed directory instead, too.) > [...] > Reading. grep -r on two src/ directories in parallel: > UFS: 84s > UFS+SU: 138s > gjournal(1): 102s > gjournal(2): 89s > > 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. Maybe it is because of the atime updates. You'll get a lot of them when grepping recursively on the src tree. 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. "Clear perl code is better than unclear awk code; but NOTHING comes close to unclear perl code" (taken from comp.lang.awk FAQ)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200606191511.k5JFBrnY017899>