The problem Rainer Toebbicke described some time ago that directories had some dirt in the high order 32 bits of the file length is understood:

When running the salvager with -salvagedirs it copies all directories into new inodes and updates the vnode. To do that it used

VNDISK_SET_LEN(&vnode, Length(&newdir));

Length() returns only an int not afs_size_t. So at least on bigendian SUNs length_hi is filled with dirt.

I experiencd here also on Linux another "nice" problem: After salvage with -salvagedirs directories which had contained the famous .__afsXXX files where corrupted, actually had length 0. Then the next salvage would find many orphans...

The reason was that when these .__afsXXX files (or other oddities) appear the salvager does a CopyOnWrite copying once again the contents of the directory. On namei-Fileservers the pseudo-inode could have the same tag the one -salvagedirs had deleted before had had. Unfortunately the deleted file had still an open file descriptor, so the new copy went into the unlinked file while the newly created remained empty!

Additionally I also changed the define for FSYNC_SALVAGE from 1 (which means V_READONLY) to 4 which forces the volume off-line in the fileserver giving "busy" to the users during salvage.

This patch was created for the rxosd environment, so line number may be slightly different for normal openafs-1.4.7, but I think it schould be possible to find the right place...

Hartmut

--- vol-salvage.c       (revision 80)
+++ vol-salvage.c       (working copy)
@@ -1797,7 +1797,8 @@
                        || vsp->header.parent == singleVolumeNumber)) {
                    (void)afs_snprintf(nameShouldBe, sizeof nameShouldBe,
                                       VFORMAT, vsp->header.id);
-                   if (singleVolumeNumber)
+                   if (singleVolumeNumber
+                     && vsp->header.id != singleVolumeNumber)
                        AskOffline(vsp->header.id);
                    if (strcmp(nameShouldBe, dp->d_name)) {
                        if (!Showmode)
@@ -2874,10 +2875,12 @@
     struct VnodeClassInfo *vcp = &VnodeClassInfo[vLarge];
     Inode oldinode, newinode;
     DirHandle newdir;
+    FdHandle_t *fdP;
     afs_int32 code;
     afs_sfsize_t lcode;
     afs_int32 parentUnique = 1;
     struct VnodeEssence *vnodeEssence;
+    afs_size_t length;

     if (Testing)
        return;
@@ -2912,7 +2915,7 @@
                   vnode.uniquifier,
                   (vnode.parent ? vnode.parent : dir->vnodeNumber),
                   parentUnique);
-    if (code == 0)
+    if (code == 0)
        code = DFlush();
     if (code) {
/* didn't really build the new directory properly, let's just give up. */
@@ -2933,7 +2936,8 @@
     }
     vnode.cloned = 0;
     VNDISK_SET_INO(&vnode, newinode);
-    VNDISK_SET_LEN(&vnode, Length(&newdir));
+    length = Length(&newdir);
+    VNDISK_SET_LEN(&vnode, length);
     lcode =
        IH_IWRITE(vnodeInfo[vLarge].handle,
                  vnodeIndexOffset(vcp, dir->vnodeNumber), (char *)&vnode,
@@ -2950,8 +2954,13 @@
 #else
     vnodeInfo[vLarge].handle->ih_synced = 1;
 #endif
+    /* make sure old directory file is really closed */
+    fdP = IH_OPEN(dir->dirHandle.dirh_handle);
+    FDH_REALLYCLOSE(fdP);
+
     code = IH_DEC(dir->ds_linkH, oldinode, dir->rwVid);
     assert(code == 0);
+
     dir->dirHandle = newdir;
 }

--- fssync.h    (revision 80)
+++ fssync.h    (working copy)
@@ -33,9 +33,10 @@
/* Reasons (these could be communicated to venus or converted to messages) */

 #define FSYNC_WHATEVER         0       /* XXXX */
-#define FSYNC_SALVAGE          1       /* volume is being salvaged */
+#define FSYNC_READONLY         1       /* same as V_READONLY  */
 #define FSYNC_MOVE             2       /* volume is being moved */
#define FSYNC_OPERATOR 3 /* operator forced volume offline */
+#define FSYNC_SALVAGE          4       /* volume is being salvaged */


 /* Replies (1 byte) */
-----------------------------------------------------------------
Hartmut Reuter                  e-mail          [EMAIL PROTECTED]
                                phone            +49-89-3299-1328
                                fax              +49-89-3299-1301
RZG (Rechenzentrum Garching)    web    http://www.rzg.mpg.de/~hwr
Computing Center of the Max-Planck-Gesellschaft (MPG) and the
Institut fuer Plasmaphysik (IPP)
-----------------------------------------------------------------
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel

Reply via email to