dafs-avoid-assert-while-moving-volumes-20080714
authorTom Keiser <tkeiser@sinenomine.net>
Mon, 14 Jul 2008 14:37:58 +0000 (14:37 +0000)
committerDerrick Brashear <shadow@dementia.org>
Mon, 14 Jul 2008 14:37:58 +0000 (14:37 +0000)
LICENSE IPL10

The volume state is perfectly consistent. FSYNC_NEEDVOLUME (and the
other state in the pending_vol_op object) is perfectly normal -- it
simply means the volser has exclusive access to the volume for the
purposes of cloning. The bug is that during the DAFS development, I
changed the semantics of the VGetVolume interface without updating the
control logic in afsfileprocs accordingly:

In 1_4_x:
vp->specialstatus != 0 results in returning vp with nUsers incremented
and *ec = vp->sepcialstatus

In DAFS:
V_AttachState(vp) == VOL_STATE_UNATTACHED results in returning a NULL
vp. Since (vp->specialstatus != 0), *ec = vp->specialstatus.

The net result is we need to modify the VBUSY logic in CheckVnode().

src/viced/afsfileprocs.c

index 09385c5..2af9cd1 100644 (file)
@@ -559,6 +559,14 @@ CheckVnode(AFSFid * fid, Volume ** volptr, Vnode ** vptr, int lock)
             * must check local_errorCode because demand attach fs
             * can have local_errorCode == VSALVAGING, errorCode == VBUSY */
            else if (local_errorCode == VBUSY && lock == READ_LOCK) {
+#ifdef AFS_DEMAND_ATTACH_FS
+               /* DAFS case is complicated by the fact that local_errorCode can
+                * be VBUSY in cases where the volume is truly offline */
+               if (!*volptr) {
+                   /* volume is in VOL_STATE_UNATTACHED */
+                   return (errorCode);
+               }
+#endif /* AFS_DEMAND_ATTACH_FS */
                errorCode = 0;
                break;
            } else if (errorCode)