[1027] in linux-scsi channel archive
Re: more scsi errors :(
daemon@ATHENA.MIT.EDU (Gerard Roudier)
Tue Nov 26 17:39:59 1996
Date: Wed, 27 Nov 1996 00:33:04 +0000 (GMT)
From: Gerard Roudier <groudier@club-internet.fr>
To: Holger Schwenk <schwenk@iro.umontreal.ca>
cc: Jon Lewis <jlewis@inorganic5.fdt.net>, "Theodore Y. Ts'o" <tytso@mit.edu>,
ncr53c810@colorado.edu,
Linux SCSI Mailing List <linux-scsi@vger.rutgers.edu>
In-Reply-To: <329B0E70.6CD1@iro.umontreal.ca>
Holger,
Thanks for your report.
ext2 dir blocks are filled with variable length entries, 4 bytes aligned.
I guess that inode field type, being __u32, needs alignement for
portability, since entries are processed directly from the data buffer.
(right?)
The kernel ckecks consistency of each entry prior to using it.
A data corruption in a block makes unusable the remainining data of the
block.
That is one of the rare places disk data is checked by the kernel.
So, in my opinion, lots of different things may cause ext2 entry problems,
hardware and software.
If one would report ext2 dir entry problems with a correct data block, I
would probably be surprised, but not enough to eat my hat, since hardware
problems and especially cache problems may have very amusing effects. :)
I just hope that, looking into the data block dump, as seen by the
processor, just after problem detection might help to find some possible
cause.
Gerard.
On Tue, 26 Nov 1996, Holger Schwenk wrote:
> Gerard Roudier wrote:
> >
> > Jon,
> >
> > The following patch should display in the log bad directory blocks at
> > most every 30 seconds (avoid to stuff the log too much).
> > If it is possible for you to give a try, we probably could have some
> > information about the possible cause of ext2 dir blocks corruption.
> > It is a hack. Check the source before try.
> > It worked for me.
> >
> > .... patch itself deleted to save space ....
>
> Hello,
>
> with respect to the recent discussion about corrupted directory entries
> on
> SCSI drives I would like to add that I've had similar errors some weeks
> ago.
> I don't remember exactly the syntax, but there were very similar to
> those
> reported in this list some days ago.
>
> However, I've got these errors on an EIDE system (Quantum Fireball 2.1
> GB)
> with no SCSI at all !!!
> It happened to me when I unpacked a 128 Mb tar-archive (the Redhat RPMS
> directory). I'vo also checked the filesystem immedeatly, but with no
> errors.
>
> Maybe this is a bug that happens under some very particular conditions,
> for instance when creating directories containing a lot of big files ??
>
> I should also add that I did the same operation later without any error
> (but I'am not sure if it was the same kernel since I installed and
> deinstalled
> my systemn several times ;-).
>
> This information is probably not very helpful, but at least it seems
> that
> the problems are not due to errors in the SCSI drivers.
