Theodore Tso wrote: > On Fri, Feb 22, 2008 at 09:02:56AM -0600, Eric Sandeen wrote: >> Theodore Tso wrote: >>> This looks good, but I assume that the bug was caused by some race >>> condition where if you try to call dm_task_get_info() while some other >>> process is creating or removing a snapshot, dm_task_get_info() is >>> returning some kind of EAGAIN, or some other "Try again; we're busy" >>> error, right? >>> >>> If that is the case, can you try to find out what error is being >>> returned? It may be the right thing to do is to check to see if we >>> are getting a "resource is locked; try again in a sec" error message, >>> and retry the dm_task_get_info(), instead of just returning a failure. >> well, dm_task_get_info just returns either 0 or 1; unless there is some >> other contextual piece of information to use, I don't know if we can >> differentiate between error types. I'll ask agk... > > Maybe the right thing is to try 3 times before giving up, maybe with a > nanosleep in between, or some such? Hopefully agk can give us some > hints about what's the right way to handle errors from all of the > dm_task* calls. >From a quick chat with agk, it sounds like outright failure is appropriate. Sounds like most of the calls fail for reasons like ENOMEM (but it might be nice if it returned that, eh?) -Eric - 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
