Date: Mon, 19 Jun 2006 20:03:16 +0200 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: "R. B. Riddick" <arne_woerner@yahoo.com> Cc: freebsd-fs@FreeBSD.org Subject: Re: Journaling UFS with gjournal. Message-ID: <20060619180316.GA3460@garage.freebsd.pl> In-Reply-To: <20060619153729.97388.qmail@web30312.mail.mud.yahoo.com> References: <20060619143231.GF1130@garage.freebsd.pl> <20060619153729.97388.qmail@web30312.mail.mud.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 19, 2006 at 08:37:29AM -0700, R. B. Riddick wrote: +> --- Pawel Jakub Dawidek <pjd@FreeBSD.org> wrote: +> > On Mon, Jun 19, 2006 at 06:37:06AM -0700, R. B. Riddick wrote: +> > +> --- Pawel Jakub Dawidek <pjd@FreeBSD.org> wrote: +> > +> > 2. If we have file system, synchronize it. +> > +> > 3. Mark file system as clean. +> > +> > 4. Block all write requests to the file system. +> > +> > +> > +> Shouldn't we do 4. before 2.? +> >=20 +> > 4 is done via vfs_write_suspend() function, which synchronize file +> > system once again. +> > +> OK. Does vfs_write_suspend mark the file system as clean again, too? +> I mean: What if bewteen step 3 and 4 someone makes the file system dirty? The order of those points isn't really exact. It was more to illustrate what's going on in there. The order in the code is correct. The file system is marked as clean when there cannot be more write requests and when file system is fully synchronized. +> > As I said gjournal is below file system layer. It receives I/O requests +> > only and cannot say which one is related to growing file, which has +> > metadata inside, etc. +> >=20 +> Yeah, below -- as u said in the email, I responded to... +> I thought, the file system code supports gjournal somehow in that point,= too... +> And I was too lazy to look into the patch u provided... +>=20 +> Might it be possible to get some more optional assistance by the file sy= stem? +> Maybe we could provide a /dev/ad0.gjournal and a /dev/ad0.fs-data, which= would +> break the GEOM concept a little bit...? *sigh* +> Maybe the file system code could use negative block numbers or high block +> numbers (somehow like a hint: U can write it right to the file system wi= thout +> any worries)? +> Of course those quick-write-through blocks should not be subject to a re= move +> operation in the currently active journal area (I mean just in case, the= system +> crashes while that journal is still active)... It's quite complex and not really nice to store such informations inside bio structure, but I hope current gjournal is only a start, there is a lot of room for improvements. For example synchronizing file system isn't cheap, but before gjournal its speed wasn't really important, now it is more important, and speeding it up will speed up gjournal. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --u3/rZRmxL6MmkK24 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFElubkForvXbEpPzQRArw+AKDCuu2y6bN9leuWLgimFsDcpSIldgCg5PJv 51ut2SUF970asHSskv+DMpY= =Fojd -----END PGP SIGNATURE----- --u3/rZRmxL6MmkK24--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060619180316.GA3460>