Messages in this thread | | | Date | Sat, 15 May 2004 09:18:38 -0400 | From | Theodore Ts'o <> | Subject | Re: [Ext2-devel] Re: [RFC/RFT] [PATCH] EXT3: Retry allocation after journal commit |
| |
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 the time.
> > 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.
- Ted - 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/
| |