On 03/07/2012 03:52 PM, Chuck Lever wrote: > > On Mar 7, 2012, at 3:50 PM, J. Bruce Fields wrote: > >> On Wed, Mar 07, 2012 at 03:36:49PM -0500, bfields wrote: >>> On Wed, Mar 07, 2012 at 02:56:30PM -0500, Steve Dickson wrote: >>>> This problem can occur when multiple cluster services fail over >>>> at the same time, causing missing high-available exports. >>>> Having a lot of nfs-exports will trigger this issue easier. >>> >>> Isn't the locking in support/export/xtab.c supposed to take care of >>> this? >> >> Huh, maybe that's just meant to prevent etab from getting corrupted, or >> mountd from seeing a partially-written file. >> >> But it probably doesn't prevent two exportfs processes from both reading >> etab, adding an export, and each writing out an etab with its one export >> added, with the last writer winning. >> >> Was that the problem? > > For bug 224, yes. After disparate concurrent exportfs commands race, the etab file ends up missing some exports. This morning I took another look at this and there does indeed need to be some global lock to stop to serialize dueling exportfs commands. The locks in xtab.c are just to granular.... steved. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
