howardl@wb3ffv.ampr.org ( WB3FFV) (01/29/91)
Hello Everybody, I was just asked a question earlier today that I tought was worth bringing to the net. I have a customer that is using RFS under AT&T V/386 Release 3.2.2 with the new StarGroup LanManager server package to link several machines together. The machines seem to work fine untill you try and cpio somthing across the RFS mounted file systems, and then bang, one of the servers will panic. As long as they don't use cpio over RFS all is OK, and if they do use cpio it will die everytime with no questions asked. They were talking with the vendor they got the equiptment and they vendor claims that you CAN NOT use CPIO over RFS, and they asked if I was aware (or in agreement) with this. I didn't really know how to answer this other than to say I had never been informed of such a problem. Is anybody here on the net aware of such a limitation within CPIO ?? If there is such a limitation, would using AFIO make any difference?? The next interesting thing they were told is that you can't use CPIO from inside cron, as cpio has a timout builtin, and that if it runs to the end of tape for some reason, it will timeout and abort. My question is, is anyone on the net aware of an inactivity timer in CRON or CPIO ?? I have never been told of any such timers, but with UNIX I never rule out the possibility of somthing going by unnoticed. Well I suppose I will sit back and see what interesting opinions float in... ------------------------------------------------------------------------------- Internet : howardl@wb3ffv.ampr.org | Howard D. Leadmon UUCP : wb3ffv!howardl | Advanced Business Solutions TELEX : 152252474 | 210 E. Lombard St - Suite 410 FAX : (301)-244-8790 | Baltimore, MD 21202 PACKET : WB3FFV @ WB3FFV.MD.USA.NA | Phone: (301)-576-8635
cpcahil@virtech.uucp (Conor P. Cahill) (01/29/91)
In article <3813@wb3ffv.ampr.org> howardl@wb3ffv.ampr.org ( WB3FFV) writes: >machines together. The machines seem to work fine untill you try and >cpio somthing across the RFS mounted file systems, and then bang, one of >the servers will panic. As long as they don't use cpio over RFS all is There *shouldn't* be a problem with using cpio over RFS file systems, but I don't have an RFS setup handy to test it. I would say that the RFS implementation has a serious bug if using CPIO causes a panic. How about more info on the problem like what cpio command, and which end of the RFS panics (the client or the server), whether the output of the cpio is going to yet another RFS partition, etc. >on the net aware of such a limitation within CPIO ?? If there is such a >limitation, would using AFIO make any difference?? I would try it. I can't think of any reason that CPIO would cause a problem where AFIO wouldn't, but who knows? >The next interesting thing they were told is that you can't use CPIO from >inside cron, as cpio has a timout builtin, and that if it runs to the end of >tape for some reason, it will timeout and abort. My question is, is anyone Actually the timeout doesn't matter. You can't use CPIO from within cron if the cpio may take more than one volume because the standard input for a cron job is /dev/null, so cpio will never get a response for loading the second volume. If you want the CPIO to run from cron, you have to ensure that it only takes one volume. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc. uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
les@chinet.chi.il.us (Leslie Mikesell) (01/30/91)
In article <3813@wb3ffv.ampr.org> howardl@wb3ffv.ampr.org ( WB3FFV) writes: > > Hello Everybody, > >I was just asked a question earlier today that I tought was worth bringing >to the net. I have a customer that is using RFS under AT&T V/386 Release >3.2.2 with the new StarGroup LanManager server package to link several >machines together. The machines seem to work fine untill you try and >cpio somthing across the RFS mounted file systems, and then bang, one of >the servers will panic. As long as they don't use cpio over RFS all is >OK, and if they do use cpio it will die everytime with no questions asked. I use cpio over RFS all the time, but I execute it from the machine with the tape drive reading the files across the RFS mount. Are they writing to the tape device across the RFS mount? (That should work as well as long as all machines have the same byte ordering and the same release of the device driver, but it's always been too slow to suit me). >They were talking with the vendor they got the equiptment and they vendor >claims that you CAN NOT use CPIO over RFS, and they asked if I was aware >(or in agreement) with this. I didn't really know how to answer this other >than to say I had never been informed of such a problem. Is anybody here >on the net aware of such a limitation within CPIO ?? If there is such a >limitation, would using AFIO make any difference?? It's a pretty silly concept if they are talking about reading the files across RFS. Cpio has to use the open(), read(), etc., system calls just like everybody else. If those system calls don't work for cpio, how can they work properly elsewhere? >The next interesting thing they were told is that you can't use CPIO from >inside cron, as cpio has a timout builtin, and that if it runs to the end of >tape for some reason, it will timeout and abort. My question is, is anyone >on the net aware of an inactivity timer in CRON or CPIO ?? No, but the newer versions will detect end-of-media and prompt for a change by opening /dev/tty. Running from cron you are limited to a single tape. If you have something resembling rsh (remote, not restricted, shell) which SysVr3 unfortunately doesn't, you can use afio to talk to a remote copy of itself for backups to remote devices. Hmmm... It probably wouldn't be difficult at all to modify afio to talk across starlan. Just add a service with nlsadmin that starts afio with the undocumented -I or -O options and either add the code to request the connection directly to afio or make another program to set up the link and pass the data on a pipe. Les Mikesell les@chinet.chi.il.us
henkd@idca.tds.philips.nl (Henk Dekker) (01/31/91)
In article <3813@wb3ffv.ampr.org> howardl@wb3ffv.ampr.org ( WB3FFV) writes: > > Hello Everybody, > >I was just asked a question earlier today that I tought was worth bringing >to the net. I have a customer that is using RFS under AT&T V/386 Release >3.2.2 with the new StarGroup LanManager server package to link several >machines together. The machines seem to work fine untill you try and >cpio somthing across the RFS mounted file systems, and then bang, one of >the servers will panic. As long as they don't use cpio over RFS all is >OK, and if they do use cpio it will die everytime with no questions asked. The only problem I found when using RFS of AT&T V/386 Release 3.2.2 was that the system paniced when a remote streams file was accessed. This occured to me when I had remote mounted /usr from the server and then tried to copy that filesystem to my local filesystem. It paniced when the file /usr/nserve/nspip was accessed. Sometimes the server panics immediately, sometimes a while after. -- # Henk Dekker Internet henkd@idca.tds.philips.nl # # Philips IS, Dept BP/PLG-i # # P.O. Box 245 UUCP ...!mcsun!philapd!henkd # # 7300 AE Apeldoorn, The Netherlands Phone +31 55 412647 #
ed@swift.CECNYE (Edward Betancourt) (02/05/91)
>> >> Hello Everybody, >> >>I was just asked a question earlier today that I tought was worth bringing >>to the net. I have a customer that is using RFS under AT&T V/386 Release >>3.2.2 with the new StarGroup LanManager server package to link several >>machines together. The machines seem to work fine untill you try and >>cpio somthing across the RFS mounted file systems, and then bang, one of >>the servers will panic. As long as they don't use cpio over RFS all is >>OK, and if they do use cpio it will die everytime with no questions asked. >The only problem I found when using RFS of AT&T V/386 Release 3.2.2 was >that the system paniced when a remote streams file was accessed. This >occured to me when I had remote mounted /usr from the server and then tried >to copy that filesystem to my local filesystem. It paniced when the file >/usr/nserve/nspip was accessed. >Sometimes the server panics immediately, sometimes a while after. Interesting that I caught this particular thread when I did. Just last week our server also died (not for the first time mind you) while attempting to cpio files across an RFS mounted partition. First the preliminaries: Client ============================== AT&T 6386E WGS AT&T Unix Sys V/386 R3.2 StarGROUP Software Version 3.2 RFS 1.2 version 2.0 Server ============================== AT&T 3B2/1000 Model 80 AT&T Unix SysV R3.2.2 StarLAN Network program Release 3.1 RFS Issue 3.2.2 version 3 Now the scenario: Advertise a directory on the 3B2. For arguments sake we'll use '/usr/local/bin'. Mount this resource onto an empty directory on the 386 client, say '/usr/ed/bin'. On the 386, 'cd' to '/usr/local/wp/bin'. Execute the following command: find . -print | cpio -pdmv /usr/ed/bin Sometimes the server (3B2) dies, and sometimes it doesn't. When it does die it displays a message like the following: TRAP proc=2044B518 psw=1872B pc=4002A17F PANIC: Kernel MMU Fault (F_ACCESS) Prior to last July this happened each and every time (although I don't recall if the console error message was exactly the same - was similar though) I tried to use cpio in the above manner. When I reversed the direction it wasn't quite as predictable but still died more often than not. Sometimes both machines would die. Calls to the AT&T Hotline resulted in their sending me a new version of 'DU' for the 3B2, which is located in the '/boot' directory. This was supposed to fix a byte ordering problem between the two different machine architectures. Sure enough it seemed to fix it until I tried doing this last Friday with a 12 MB directory structure. I don't believe that I've tried copying such a large amount of stuff after I received the fix until now. Needless to say I was very concerned about it (that's putting it very mildly) since the last time this happened it caused enough damage that I had to perform a full restore. Luckily that didn't happen this time but we still had to wait over an hour for the machine to 'fsck' through 2.4 GB of online disk space. This usually doesn't make for very happy end users (or administrators :-( ). No remote streams files or special devices of any kind were accessed so what gives? They were just plain programs (none in use at the time) and data files being copied across the network. Well, it's back to the ol' Hotline for me, to try to get a definitive fix (if one exists) for this problem. I felt I had to share this experience after having seen that I wasn't the only one having this problem. To all others experiencing a similar problem fear not, you're not alone. If I get any REAL answers, I'll post them. Regards, Ed -- ---------------------------------------------------------------------------- Edward Betancourt ..uunet!swift!ed