Christopher D. Clausen wrote:
John Koyle <[EMAIL PROTECTED]> wrote:
I've been running a small single server cell on 1.4.0-rc4 for some
time and am just now adding a second server to the mix. I installed
1.4.2fc2 on the second machine and successfully moved several volumes
to it with no problems.
What OS are you running these on?
This is on Debian stable with 2.6.16-18 kernel from backports.org. AFS
is self compiled on the box using: ./configure
--with-afs-sysname=i386_linux26 --enable-transarc-paths and gcc 3.3.5.
Last week when fc3 came out I upgraded the second machine from fc2 to
fc3. Migrating additional volumes now seems to work, but the process
fails at the end when it tries to clean up the source:
[EMAIL PROTECTED]:~$ vos move home.user server1 /vicepa server2 /vicepa
Failed to create a transaction on the source volume 536870984
VOLSER: volume is busy
vos move: operation interrupted, cleanup in progress...
clear transaction contexts
move incomplete - attempt cleanup of target partition - no guarantee
cleanup complete - user verify desired result
This leaves server1 in a bit of disarray as well with **** Could not
attach volume 536870984 ****
in the output of vos listvol. I believe the contents of this volume
are now empty, and have simply removed the volume entry in /vicepa to
clean it up (this may be a bad thing though).
However, as mentioned above, the volume is fine on server2 and behaves
as expected.
Did something change between fc2 and fc3 that may have caused this?
Hmm... I actually had this problem with fc2 as well (on sun4x_510.) I
thought it was fixed in fc3. I guess I need to do some more testing...
Do you by chance have any errors in the server logs?
Yes, but nothing very verbose at this point.
server 2's FileLog:
Tue Sep 12 22:07:56 2006 fssync: volume 536871110 moved to 561e140a;
breaking all call backs
Tue Sep 12 22:07:56 2006 fssync: volume 536871110 restored; breaking all
call backs
Tue Sep 12 22:07:56 2006 VAttachVolume: Failed to open
/vicepa//V0536871110.vol (errno 2)
Tue Sep 12 22:07:56 2006 VAttachVolume: Error reading namei vol header
/vicepa//V0536871113.vol; error=101
Tue Sep 12 22:07:56 2006 VAttachVolume: Error attaching volume
/vicepa//V0536871113.vol; volume needs salvage; error=101
Tue Sep 12 22:07:56 2006 VAttachVolume: Error reading namei vol header
/vicepa//V0536871113.vol; error=101
Tue Sep 12 22:07:56 2006 VAttachVolume: Error attaching volume
/vicepa//V0536871113.vol; volume needs salvage; error=101
server 2's VolserLog:
Tue Sep 12 22:07:38 2006 1 Volser: CreateVolume: volume 536871110
(home.bob) created
Tue Sep 12 22:07:56 2006 1 Volser: Clone: Cloning volume 536871110 to
new volume 536871113
Tue Sep 12 22:07:56 2006 1 Volser: Delete: volume 536871110 deleted
Tue Sep 12 22:07:56 2006 VAttachVolume: Failed to open
/vicepa/V0536871112.vol (errno 2)
Tue Sep 12 22:07:56 2006 VAttachVolume: Error reading namei vol header
/vicepa/V0536871113.vol; error=101
Tue Sep 12 22:07:56 2006 VAttachVolume: Error attaching volume
/vicepa/V0536871113.vol; volume needs salvage; error=101
Tue Sep 12 22:07:56 2006 VAttachVolume: Failed to open
/vicepa/V0536871112.vol (errno 2)
Tue Sep 12 22:07:56 2006 VAttachVolume: Failed to open
/vicepa/V0536871110.vol (errno 2)
Tue Sep 12 22:07:56 2006 VAttachVolume: Error reading namei vol header
/vicepa/V0536871113.vol; error=101
Tue Sep 12 22:07:56 2006 VAttachVolume: Error attaching volume
/vicepa/V0536871113.vol; volume needs salvage; error=101
Server 1's FileLog (the destination for the move)
Tue Sep 12 22:07:56 2006 fssync: volume 536871110 restored; breaking all
call backs
Tue Sep 12 22:07:56 2006 fssync: volume 536871110 restored; breaking all
call backs
Server 1's VolserLog:
Tue Sep 12 22:07:56 2006 VAttachVolume: Failed to open
/vicepa/V0536871110.vol (errno 2)
Tue Sep 12 22:07:56 2006 1 Volser: CreateVolume: volume 536871110
(home.bob) created
Did any instances crash and dump core?
No not yet.
See bug: http://rt.central.org/rt/Ticket/Display.html?id=38566
This sounds similar to the problem I'm having. If it's intermittent
that may explain why the moves were working previously?
John
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
