Re: ext3 weirdness

[Andreas Dilger <adilger@clusterfs.com>]

On Apr 12, 2003  03:06 +1000, CaT wrote:
> Why would this:
> 
> while true; do dd if=/dev/zero of=foo count=100 bs=10000; rm foo; done
> 
> Produce the following result?
> 
> ...
> 100+0 records in
> 100+0 records out
> 100+0 records in
> 100+0 records out
> dd: writing `foo': No space left on device
> 70+0 records in
> 69+0 records out
> dd: writing `foo': No space left on device
> 1+0 records in
> 0+0 records out
:
> dd: writing `foo': No space left on device
> 1+0 records in
> 0+0 records out
> 100+0 records in
> 100+0 records out
> 100+0 records in
> 100+0 records out
> ...

Because you can't reallocate in-use blocks until the dirty bitmaps have
been committed to disk in a transaction.

What should probably happen is that in ext3_new_block() we should flush
the journal (once!) if we are going to return -ENOSPC and restart
the allocation attempt.

This may be easy (just calling journal_flush()) or it may be more effort,
depending on how the locking looks.  I think journal_flush() is no good,
because by the time ext3_new_block() is called we always have a journal
handle, and I believe journal_flush() will wait for all transactions to
complete -> deadlock.

Maybe something like (just a guess):

+	int flushed = 0;

	:
	:
+repeat:
	/*
	 * First, test whether the goal block is free.
	 */

	:
	:

	/* No space left on the device */
+	if (!flushed && journal->j_committing_transaction) {
+		transaction = journal->j_committing_transaction;
+		log_wait_commit(journal, transaction->t_tid);
+		flushed = 1;
+		goto repeat;
+	}
+
	goto out;

search_back:

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/