All pre-1.4.8 file servers (going back to IBM) have a bug where the volume will be reported VNOVOL instead of VBUSY/VMOVED while the move is taking place. This happens before the move has completed so when the clients go back to the VLDB to update the location info they are told that the location is the same as it thought it was. For the next two hours the client will attempt to find the volume in the wrong place until the VL info expires or "fs checkvolumes" is issued.
This bug is fixed by DELTA STABLE14-volser-reclone-bring-online-before-giveback-20080716 which can be applied to 1.4.7 although at this point you might just want to use the 1.4.8-preX servers. Jeffrey Altman Eric Chris Garrison wrote: > Harald Barth wrote: >>> I decided to upgrade our servers from 1.4.4 to 1.4.7 this week, so I was >>> going to do rolling upgrades, that is, moving volumes from one server to >>> another, upgrade the server, then move them back and so on. This time, we >>> find that Samba claims to not be able to see the volume. >> What client version on the samba gateway? >> Is "fs checkv" after the move a workaround? >> >> Harald. > > > Samba is at version 3.0.25b-1.el4.4 on our gateways. I'm not sure if > that's a workaround, since I've been unable to reproduce the behavior, it > is just certain random users. Must be a special case, maybe they're using > the volume right as the move happens? I'm baffled. I could include it in > the mvto script. That or a fs flush? > > Thanks, > > Chris
smime.p7s
Description: S/MIME Cryptographic Signature
