![]() | |||||||||||||
Messages in this thread |
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/ | ||||||||||||
| Last update: 2005-03-22 13:03 [from the cache] ©2003-2008 | |||||||||||||