> --On Monday, December 06, 2004 07:48:52 PM +0100 Jeffrey Altman > <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] "/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 _______________________________________________ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
