[OpenAFS-devel] stability problems, and interesting symptoms. ..

[Jeffrey Hutzelman]

On Wed, 30 May 2001, Neulinger, Nathan wrote:

> Something else that looks odd:
> 
> from VAttachVolumeByName_r:
> 
>     *ec = 0;
>     strcpy(path, VPartitionPath(partp));
>     strcat(path, "/");
>     strcat(path, name);
>     VOL_UNLOCK
>     if ((fd = open(path, O_RDONLY)) == -1 || fstat(fd,&status) == -1) {
>         close(fd);
>         VOL_LOCK
>         Log("VAttachVolume: Error opening/statting volume header file
> (%s)\n", path);
>         *ec = VNOVOL;
>         goto done;
>     }
>     n = read(fd, &diskHeader, sizeof (diskHeader));
> 
> 
> whenever I move a volume off the server - that error case with open/stat -
> is ALWAYS triggering.
> 
> May 30 12:19:44 afs4 fileserver[2915]: VAttachVolume: Error opening/statting
> volume header file (/vicepb//V0536897242.vol) 
> 
> I'm not sure if the above is actually an error condition, but that double
> slash is a bit odd. It looks like the double slash does actually work ok in
> the open() call, but still odd that this case is getting triggered all the
> time, unless this is some weird "try and attach the volume after it was
> deleted, just to make sure it was deleted" type of thing.

This is normal.  Remember that whenever a volume utility attaches a
volume, it must first "get" the volume from the fileserver via the fssync
interface.  There are a variety of modes, but anything that involves
changing the volume always gets it in a mode where the fileserver takes
the volume offline (or marks it busy), and other volume utilities are not
allowed to attach the volume.  When the operation is complete, the volume
utility "gives back" the volume, again via the fssync interface.  This
causes the fileserver to attempt to reattach the volume; for a moved or
deleted volume, this always fails.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
   Carnegie Mellon University - Pittsburgh, PA