Subject: Re: FFS journal
To: None <pavel.cahyna@st.mff.cuni.cz,>
From: Pawel Jakub Dawidek <pjd@FreeBSD.org>
List: tech-kern
Date: 07/09/2006 11:58:33
--57SHPaztv6dlLu/a
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jul 03, 2006 at 06:47:43PM +0200, Pavel Cahyna wrote:
> Hi,
>=20
> On Sun, Jul 02, 2006 at 07:59:50PM +0400, Kirill Kuvaldin wrote:
> > IV. OPEN ISSUES
> >=20
> > * Journal location: The journal can reside on the same device as the
> >   rest part of file system does, but putting the journal on the
> >   different device may be a performance win. E.g., Seltzer paper [3]
> >   describes the approach when the journal is managed by write-ahead
> >   filesystem (wafs). It may require some additional time to implement
> >   the similar functionality.
> > * The maximum size of a transaction is to be determined.
> >   The jffs_start_transaction() function uses this information to ensure
> >   that there is enough space available to hold the new transaction.
> > * The functionality for recovering after the crashes (journal replaying)
> >   need to be clearly defined and added to this document.
> > * Probably the list of transactions must be extended.
>=20
> If an application unlinks a file which is opened, the file is not deleted
> until it is closed, until that it exists as unnamed. Now if the system
> crashes after the unlink and before the close, the unnamed file is not
> deleted and remains in the filesystem, taking up space. This is not a
> problem in a non-journalling scenario, because after a crash fsck is run
> and takes care of it. But a journalling filesystem should take this into
> account.

Maybe you guys will find my experience helpful. I'm working on gjournal
(a block level journaling) for FreeBSD and I needed to solve this
problem as well.

My first solution to the problem was a magic .deleted/ directory, which
was created on mount time. Now, when an object (file or directory) was
removed, but still open, it wasn't really removed, but moved to
=2Edeleted/ directory. On close the object is removed from this directory.
You need to ensure that such file/directory cannot be moved back to the
file system. On system crash or a power failure all you need to do is to
'rm -rf .deleted' directory.
It worked without problems, but it wasn't really nice, so I implemented
another thing...

When an object is removed, but still open, I increase two counters:
1. fs_unref - total number of unreferenced inodes in the file system
   (stored in file system's super-block).
2. cg_unref - total number of unreferenced inodes in this cylinder
   group.
After a system crash or a power failure, I run faster fsck version,
which scans only cylinder groups looking of cg_unref > 0. If it finds
such cylinder group, it scans all its inodes looking for those with
linkcnt =3D=3D 0. Then, it just free all its blocks and marks it as
unallocated. Of course, because of the global fs_unref counter we don't
have to scan the whole file system, but quit scanning if fs_unref goes
to 0.

--=20
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd@FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!

--57SHPaztv6dlLu/a
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)

iD8DBQFEsNNJForvXbEpPzQRAkiYAJ9EAZy07+JusWgoo0w96tuTi4AxKwCg109J
9ZNXAzug0LE3bNG+DUZoaAg=
=rmBA
-----END PGP SIGNATURE-----

--57SHPaztv6dlLu/a--