[OpenAFS] Re: rough timeline for 1.4.x

[Tony D'Amato]

> --On Monday, December 06, 2004 07:48:52 PM +0100 Jeffrey Altman
> <jaltman@columbia.edu> wrote:
> The thing which is preventing the release of 1.3.7x as a stable 1.4
> tree is lack of deployment and testing by users.  There has been very
> little feedback both positive or negative on the existing releases.
> Without this feedback it is very difficult for us to know whether or
> not it is ready.

Well, we've been running starting with OpenAFS 1.3.70 thru 1.3.76 with
Dell 2650's running patched Red Hat 9. We've got Solaris 8 clients which
have been running OpenAFS 1.3.70 thru 1.3.76 also. We were a little
concerned when switching the file servers over to large file support,
but that went a lot smoother than we anticipated. All clients have a one
gigabyte /usr/vice/cache slice/partition defined on them.

For the most part, things are going well, except now we're migrating our
users from our aging DCE/DFS system over to OpenAFS. We've begun to get
messages similar to the following when copying large files from one
system to another:

$ ( cd ~user1; /usr/bin/tar cpf - . ) | ssh user1@afs-client.odu.edu "/usr/bin/tar xpf -"
tar: can't set time on ./files/allcore/allcore.dta: No such file or directory

But once a 'fs flushvolume ~user1' is issued,
then ./files/allcore/allcore.dta reappears, minus the date-time stamp
adjustment from tar.

I've adjusted /usr/vice/etc/config/afsd.options by adding '-chunksize
20' - this has produced some success by reducing the number of the above
errors.

I've also tried running 1.3.70 and 1.3.71 on a small AIX 4.3.3 machine
that we use for AFS backups, but after the kernel panics we switched
back up 1.2.11 (haven't had the time to try a newer 1.3 - sigh).

Hope this helps somewhat.
---
Tony D'Amato
Senior UNIX Systems Administrator
Old Dominion University