[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Strange behavior while copying files



On Mon, Aug 06, 2001 at 11:45:10PM -0400, Roland McGrath wrote:
> > Hi, I'm trying to copy a large directory /sub to a partition mounted
> > on /local. /sub contains a functioning Hurd filesystem produced
> > from the initial tarball. I used this command
> > 
> > # cd /sub
> > # cp -a * /local/
> 
> Use -v to see each action cp is doing.
> 
> > First, it's very slow, but that's a known problem. After a while it
> > spurts out these messages and finishes:
> > 
> > cp: cannot create regular file `/local/servers/exec': Computer bought the farm
> 
> Try to reproduce this with actions just on this single file.  Most likely
> the filesystem for /local crashed.  I'm presuming it's ext2fs, but this is
> something you should spell out in a problem report (i.e. include 
> "showtrans /local").

Done. What was happening was that ext2fs was dying (hence EIEIO) and was
being restarted as readonly rightaway. The reason why it was failing
seems to be that /sub/servers/exec had a 28KB string as its translator.
ext2fs limits translator sizes to the size of a file system block. On
my system it happens to be 4KB, so it's not even possible to set that
kind of translator with settrans. I think my file system was corrupted
when I was playing around with a sub Hurd on the same partition as my /.

But this is still no excuse for ext2fs to crash faced with such an
inconsistency. The server might have printed an error message to the
console (serial console in my case), but I wasn't monitoring it. And
now I can't reproduce it anymore because I can't legally reset the
translator on /sub/servers/exec to a huge enough string again.

> > The strange thing happens when this is done, if I look in my
> > / I have a ton of pty* and tty* device files created there, even though
> > I copied no files to or from /.
> 
> This I cannot explain.  I tend to be a little skeptical that this really
> happened the way it appeared to you, since it's the only part of the
> scenario that is not readily explained by known behavior and understandable
> bugs.  Please try to reproduce the failure under controlled conditions. 

This I'm still puzzled about. :-)

Igor



Reply to: