[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Journalling filesystems

From: Bas Wijnen
Subject: Re: Journalling filesystems
Date: Wed, 16 Jun 2004 22:53:05 +0200
User-agent: Mutt/1.3.28i

On Wed, Jun 16, 2004 at 08:57:18PM +0200, Marco Gerards wrote:
> The main problem to consider here is how to prevent the journal to get
> filled too quickly.  Consider a 1GB file which you drastically change.  That
> means you will have a 1GB transaction.  Normally a journal is a lot smaller.

The journal will not be so large.  The changes are written to unused blocks on
the disk, a shadow which-blocks-are-used-for-which-file-table is created (FAT
on a DOS partition), and at the end of the transaction, it is pointed to by
the main which-blocks-are-used-for-which-file-table-pointer.

To change a 1GB file drastically, you need at least 1GB of free disk space.

It is a little more complex than this, because you can't simply make a shadow
FAT and update it.  That would mess things up with multiple transactions going
on at the same time.  So that's probably where the journal comes in, it needs
to keep a list of which blocks are going to be used by which file.  At
transaction end, the FAT is locked, shadowed (and updated), swapped, and

I could be missing some critical points though, I didn't read much about it
yet.  I don't think I'm going to work on it very soon either, so it may be a
pretty useless discussion at this point ;-)

Marcus noted that all applications need to be changed.  I don't think they do.
Only applications which have a database which can be corrupt (unlike, for
example, a music collection) want to use it.  And even they may not need it
for all disk access.  Of course the filesystem must still be able to handle
traditional access.


I encourage sending me encrypted e-mail.
Please send the central message of e-mails as plain text in the message body,
   not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
for more information, see

Attachment: pgpvVH2ft5_bS.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]