]> git.michaelhowe.org Git - packages/o/openafs.git/commitdiff
vol: Nuke parent vol special inodes
authorAndrew Deason <adeason@sinenomine.net>
Wed, 18 Sep 2013 21:56:23 +0000 (16:56 -0500)
committerStephan Wiesand <stephan.wiesand@desy.de>
Tue, 4 Mar 2014 18:07:51 +0000 (10:07 -0800)
When we "nuke" a volume, we delete all inodes we can find that are for
the given volume id. This currently means that if we nuke an RW volume
id, we delete all of the inodes for file data for the entire volume
group (since they're all stored in the VG id), but we do not delete
the special inodes for any non-RW volumes in that volume group. Those
special inodes left behind are not very useful, since we just deleted
all of the actual file data.

Currently this means that on namei, it's impossible to nuke the
special inodes for non-RW volumes, since the namei nuke will only look
in the subdir for the given volume id. If you give it the RW volume
id, it won't delete the special inodes as menioned above; if you give
it the RO volume id, it will only look in the RO subdir, and won't
find the RO special inodes in the RW subdir.

If a volume group is damaged in such a way that the salvager cannot
fix it (due to a bug), this means that it is impossible to get rid of
that volume group completely from the partition on namei without
manually running "rm -rf" on the relevant AFSIDat directory. Normally
we have a failsafe of running 'vos zap -force', but that doesn't work
for non-RW special inodes, as mentioned above.

So, in order to allow this 'vos zap -force' failsafe to work in
hopefully all situations, also delete the special inodes for the
parent volume. Use similar logic as exists in the salvager's
OnlyOneVolume function.

Reviewed-on: http://gerrit.openafs.org/10256
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
(cherry picked from commit d83c1231cf371ac998304cbb2007ca848a514e0c)

Change-Id: I80216cb73b9bc8edb7e6dca735a522d7132017dd
Reviewed-on: http://gerrit.openafs.org/10772
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: D Brashear <shadow@your-file-system.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
src/vol/nuke.c

index be8d1a7902aad5241d083706209eb5cebca590de..dc1b798aab82072a500e10e834e166717b9b1f8c 100644 (file)
@@ -65,7 +65,6 @@ struct ilist {
 
 /* called with a structure specifying info about the inode, and our rock (which
  * is the volume ID.  Returns true if we should keep this inode, otherwise false.
- * Note that ainfo->u.param[0] is always the volume ID, for any vice inode.
  */
 static int
 NukeProc(struct ViceInodeInfo *ainfo, afs_uint32 avolid, void *arock)
@@ -79,8 +78,21 @@ NukeProc(struct ViceInodeInfo *ainfo, afs_uint32 avolid, void *arock)
 #endif /* !AFS_PTHREAD_ENV */
 
     /* check if this is the volume we're looking for */
-    if (ainfo->u.param[0] != avolid)
-       return 0;               /* don't want this one */
+    if (ainfo->u.vnode.vnodeNumber == INODESPECIAL) {
+       /* For special inodes, look at both the volume id and the parent id.
+        * If we were given an RW vol id to nuke, we should delete the special
+        * inodes for all volumes in the VG, since we're deleting all of the
+        * regular inodes, too. If we don't do this, on namei would be
+        * impossible to nuke the special inodes for a non-RW volume. */
+       if (ainfo->u.special.volumeId != avolid && ainfo->u.special.parentId != avolid) {
+           return 0;
+       }
+    } else {
+       if (ainfo->u.vnode.volumeId != avolid) {
+           return 0;           /* don't want this one */
+       }
+    }
+
     /* record the info */
     if (!*allInodes || (*allInodes)->freePtr >= MAXATONCE) {
        ti = (struct ilist *)malloc(sizeof(struct ilist));