Hi,

On Sun, Jul 02, 2006 at 07:59:50PM +0400, Kirill Kuvaldin wrote:
> IV. OPEN ISSUES
> 
> * 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.

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.

> V. ADDITIONAL INFORMATION AND REFERENCES

You might find this lecture about ext3 implementation interesting:

http://olstrans.sourceforge.net/release/OLS2000-ext3/OLS2000-ext3.html

It mentions a number of issues that had to be solved when implementing
ext3, including the above one. (Search for "Orphaned files".)

Good luck	Pavel Cahyna