From: Ulf Carlsson <ulfc@thepuffingroup.com>
To: Ralf Baechle <ralf@uni-koblenz.de>
Cc: linux@cthulhu.engr.sgi.com
Subject: Re: File corruption
Date: Wed, 23 Jun 1999 01:49:23 +0200 [thread overview]
Message-ID: <19990623014923.A8953@thepuffingroup.com> (raw)
In-Reply-To: <19990622152145.A1059@uni-koblenz.de>; from Ralf Baechle on Tue, Jun 22, 1999 at 03:21:45PM +0200
On Tue, Jun 22, 1999 at 03:21:45PM +0200, Ralf Baechle wrote:
> On Tue, Jun 22, 1999 at 03:29:00AM +0200, Ulf Carlsson wrote:
>
> > This is *really* annoying, I can't do anything without getting interrupted
> > by some bug on the Indy. I can't stand this file corruption. I just lost
> > an entire directory. This isn't because of crashes, stuff just vanish, or
> > gets corrupted without any reason. I for example had a gzipped patch, I
> > decompressed it and I got a lot of junk in the middle of the file.
>
> Question, is this effect repeatable, that is if you decompress the file a
> second time, will you still see the filesystem corruption? The latter would
> mean that the data decompressed data get corrupted on the fly and the SCSI
> driver isn't involved. Or does the gzip'ed file itself already contain the
> corrupted data?
Since the file is decompressed without warnings I assume that the scp went fine.
Anyhow, when I had decompressed the file I got corruption in the middle of the
patch. The corruption affected only a couple of lines, 10 or so.
The problems I experience are not repeatable. Everything went smooth after a
reboot. I usually reboot the machine when it's messing with me, that helps. At
least for a while.
> And under which kernel version did this start to happen?
2.2.1 I think.
> Could you resend me your hinv output?
Unfortunately I don't have IRIX. However, I have a 133 MHz R4600 CPU with 512 k
board cache. I have two 1 Gb SCSI driver connected.
> > Earlier today the cached version of /lib/libpam_misc.so.0.64 was corrupted
> > or something, and corrupted ELF headers were reported. A reboot fixed that
> > one.
>
> It seems that you observe similar problems like me. For me however the
> problem has just vanished and was rare anyway.
They're rare for me as well, but I've had a couple in just a few days now.
Maybe the file corruption became heavier since 2.3.6?
> I understand that very well. Btw, I started to store important stuff on NFS.
I can't stand NFS. Files, or entire directories vanish from ls, but I may still
open them if I specify their names directly. I think I've been talking to you
about this before.
- Ulf
next parent reply other threads:[~1999-06-22 23:51 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <19990622032859.B6955@thepuffingroup.com>
[not found] ` <19990622152145.A1059@uni-koblenz.de>
1999-06-22 23:49 ` Ulf Carlsson [this message]
1999-06-24 22:28 ` File corruption Ralf Baechle
1999-06-25 13:31 ` Ulf Carlsson
1999-06-25 18:08 ` Thomas Bogendoerfer
1999-06-25 14:34 ` Andrew Linfoot
1999-06-25 14:34 ` Andrew Linfoot
1999-06-25 16:59 ` Ulf Carlsson
1999-06-25 17:11 ` Andrew Linfoot
1999-06-25 17:11 ` Andrew Linfoot
1999-06-28 10:39 ` Ralf Baechle
1999-06-28 9:34 ` Ralf Baechle
2002-09-30 19:52 File Corruption jeff leads
2002-10-01 6:10 ` Oleg Drokin
2002-10-02 4:07 ` jeff leads
2002-10-02 6:30 ` Oleg Drokin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=19990623014923.A8953@thepuffingroup.com \
--to=ulfc@thepuffingroup.com \
--cc=linux@cthulhu.engr.sgi.com \
--cc=ralf@uni-koblenz.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.