[OpenAFS] Re: vos move fails to work on new openafs fileserver, seems fine from other hosts
I have found the answer to my own problem; the issue was a line in the: /etc/hosts file like: 127.0.1.1 newserver.math.uic.edu newserver So the AFS server was trying to talk to it's loopback address while external hosts were connecting to the external IP address. Mystery solved! -Fred On Thu, Apr 5, 2018 at 7:15 PM, Fred Drueck <fdru...@uic.edu> wrote: > > > On Thu, Apr 5, 2018 at 6:56 PM, Fred Drueck <fdru...@uic.edu> wrote: > >> Hello other OpenAFS users, >> >> I've recently setup a new file server to try and facilitate upgrading our >> OpenAFS servers to a newer version of debian (the current stable distro: >> stretch). >> >> The server and db server setup seems to have gone smoothly, but I've got >> problems with moving the AFS volumes. >> >> If I try to do a vos move from the old fileserver to the new one, the >> move will fail with: >> >> Failed to move data for the volume 536881885 >> >>VOLSER: Problems encountered in doing the dump ! >> >> However, if I work on the old file server, or another openafs client >> system (in fact, I've got another debian stretch system using the exact >> same version the debian openafs-client package) I can move the volume to >> the new server. >> >> And I can verify by looking at the /vicepc directory that the file is >> there, the vldb says it's there but if I try to move the file back to the >> older server working on the new server it will fail with a message that the >> volume is not found, something like: >> >> The volume 536881885 is not on the specified site. >> The current site is : server newserver.math.uic.edu partition /vicepc >> >> OK ... but that's exactly the arguments I passed to vos as the >> -fromserver and -toserver >> >> And, if I switch over to another openafs-client or the old AFS file >> server I can issue the vos command to move the volume back just fine. >> >> Anybody have any ideas what's going wrong? >> >> -Fred >> > > Looking through the logs, the only thing I saw that looked maybe relevant > was: > > Thu Apr 5 19:02:45 2018 VReadVolumeDiskHeader: Couldn't open header for > volume 536881887 (errno 2). > > but if that's such a problem then why can the other AFS clients happily > manipulate the volume? > > It's puzzling. > > -Fred >
[OpenAFS] Re: vos move fails to work on new openafs fileserver, seems fine from other hosts
On Thu, Apr 5, 2018 at 6:56 PM, Fred Drueck <fdru...@uic.edu> wrote: > Hello other OpenAFS users, > > I've recently setup a new file server to try and facilitate upgrading our > OpenAFS servers to a newer version of debian (the current stable distro: > stretch). > > The server and db server setup seems to have gone smoothly, but I've got > problems with moving the AFS volumes. > > If I try to do a vos move from the old fileserver to the new one, the move > will fail with: > > Failed to move data for the volume 536881885 > >VOLSER: Problems encountered in doing the dump ! > > However, if I work on the old file server, or another openafs client > system (in fact, I've got another debian stretch system using the exact > same version the debian openafs-client package) I can move the volume to > the new server. > > And I can verify by looking at the /vicepc directory that the file is > there, the vldb says it's there but if I try to move the file back to the > older server working on the new server it will fail with a message that the > volume is not found, something like: > > The volume 536881885 is not on the specified site. > The current site is : server newserver.math.uic.edu partition /vicepc > > OK ... but that's exactly the arguments I passed to vos as the -fromserver > and -toserver > > And, if I switch over to another openafs-client or the old AFS file server > I can issue the vos command to move the volume back just fine. > > Anybody have any ideas what's going wrong? > > -Fred > Looking through the logs, the only thing I saw that looked maybe relevant was: Thu Apr 5 19:02:45 2018 VReadVolumeDiskHeader: Couldn't open header for volume 536881887 (errno 2). but if that's such a problem then why can the other AFS clients happily manipulate the volume? It's puzzling. -Fred
[OpenAFS] vos move fails to work on new openafs fileserver, seems fine from other hosts
Hello other OpenAFS users, I've recently setup a new file server to try and facilitate upgrading our OpenAFS servers to a newer version of debian (the current stable distro: stretch). The server and db server setup seems to have gone smoothly, but I've got problems with moving the AFS volumes. If I try to do a vos move from the old fileserver to the new one, the move will fail with: Failed to move data for the volume 536881885 VOLSER: Problems encountered in doing the dump ! However, if I work on the old file server, or another openafs client system (in fact, I've got another debian stretch system using the exact same version the debian openafs-client package) I can move the volume to the new server. And I can verify by looking at the /vicepc directory that the file is there, the vldb says it's there but if I try to move the file back to the older server working on the new server it will fail with a message that the volume is not found, something like: The volume 536881885 is not on the specified site. The current site is : server newserver.math.uic.edu partition /vicepc OK ... but that's exactly the arguments I passed to vos as the -fromserver and -toserver And, if I switch over to another openafs-client or the old AFS file server I can issue the vos command to move the volume back just fine. Anybody have any ideas what's going wrong? -Fred
[OpenAFS] /var/cache/openafs on btrfs
Hello Everyone, According to the OpenAFS admin FAQ, it appears that the officially supported file systems for the disk cache are: ext2 ext3 hfs (HP-UX) xfs (at least on IRIX 6.5) ufs (Solaris, ?Tru64Unix) which is clearly out of date, since there is a working implementation for OS X that runs on top of HFS+ For some time I've been fearlessly using both ext4 and btrfs (on Linux, as you might infer) as the backing storage for my AFS client cache. I have noticed some fairly rare issues with the clients if all file/db servers (in our cell the same machines) become unavailable. The '/afs' mount becomes un-accessible and attempts to access files often result in very long timeouts. I've always been able to fix things by somehow shutting down the client (in the worst case by physical power-off and reboot into single user mode) and deleting the cache. Is there some chance that this is because I've been causing these problems by using un-supported file-systems as the backing storage for the client cache? I'm using fairly recent versions of the client, namely the version packaged for debian-squeeze, debian-wheezy, ubuntu 14.04, and a very recent release on Arch Linux. e.g. 1.6.9-2+deb8u4~bpo70+1 Version: 1.4.12.1+dfsg-4+squeeze4 Version: 1.6.7-1ubuntu1. openafs 1.6.14.1-1 For the most part, though, I haven't had many issues. Does anyone know any updated info on what the supported client filesystems are? Thanks! -Fred
