On Wed 19-12-12 10:37:25, Ted Tso wrote: > On Wed, Dec 19, 2012 at 09:13:34AM +0100, Jan Kara wrote: > > > I was wondering if, since the tid_g*() functions only work if the > > > distance is half the unsigned int space, we can force a commit at some > > > point if j_transaction_sequence has gotten too far ahead? I'm not sure > > > where or if that could be done... > > > > I don't quiete understand. If someone stores tid = transaction->t_tid and > > in two weeks calls log_start_commit(tid), I don't see how any forcing of > > commits could solve that tid may now look ahead of the log... > > Actually, what we can do is the reverse. Right now when we modify an > inode, we stash the tid to indicate "we need to commit to at least > this tid". The problem comes if we haven't modified the inode for a > long time, but then later when we issue an fsync for that inode, it's > after a tid wrap, so we trigger the warning. > > What we could do is in cases were we aren't touching the inode note if > the tid value is obviously out of date, and set it to some value which > is one less than the current tid. This avoids the wrap, and in cases > where we are releasing the inode and nothing else is left, it's a safe > thing to do. > > The downside is that doing this would incur locking overhead, and it's > not clear it's worth it. Now that we understand what's going on, > nothing bad is happening when the warning is triggered, so we could > just remove it. > > If we use a 64-bit in-memory tid, that would help avoid cases where > the tid has wrapped and we get unlucky and hit the 1 in 2**32 case > where we trigger a commit where one is not needed. Given that the > cost of an extra commit with probably 1 in 2**32 is pretty low, it's > probably not worth the overhead of using a 64-bit tid, though.... I agree. Just I'm still somewhat puzzled by those two reports pointed to by Eric. In both cases stored tids were 0 and I cannot see how that happens (well how it could happen in a reasonably likely way). Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
