Messages in this thread | | | Date | Fri, 11 Apr 2003 11:39:41 -0600 | From | Andreas Dilger <> | Subject | Re: ext3 weirdness |
| |
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/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |