Re: [Ext2-devel] Re: [RFC/RFT] [PATCH] EXT3: Retry allocation after journal commit
From: Theodore Ts'o
Date: Sat May 15 2004 - 08:19:45 EST
On Fri, May 14, 2004 at 03:06:22PM -0600, Andreas Dilger wrote:
> > I tried that first, actually. In the test case I was trying, it only
> > worked 33% of the time. The other 66% of the time, the rm -rf all fit
> > into the current running transaction, and waiting on the previous
> > transaction wasn't sufficient to solve the problem.
> I guess the success ratio dependends on how many blocks are tied up in
> the transaction, the size of the journal, and how much free space is
> left in the filesystem. In my tests (dd to a file that does O_TRUNC and
> overwrites with the same file size) this change wasn't 100% successful
> but fixed it the majority of the time.
In my case, the filesystem was completely full, and we were doing an
"rm -rf /mntpt/*", followed by a series of mkdir to set up the test
directories. We were failing on the mkdir approximately 2/3'rds of
> > That was why I was retrying at the top-level functions: ext3_mkdir,
> > for example. There won't be a nested journal transaction there.
> Waiting for the currently committing transaction to complete would
> deadlock Lustre, because it starts journal transactions above ext3 so
> that it can write update records in the same transaction as the
> filesystem operation.
Right, I had forgotten about Lustre. :-) I was only worrying about
the nested transaction case of writing to the quota file. So what we
can do is only do the do the log_wait_commit (and retry the
transaction) if current->journal_info is NULL --- i.e., only when the
current process does not have a currently active handle. If not, we
return -ENOSPC, and let the top-level caller (Lustre in your case)
retry the entire operation.
I think that should be sufficient to keep Lustre happy.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/