CPIO, RFS, & Crontab ??

[Edward Betancourt]

>>
>>   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