public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Petr Vandrovec" <VANDROVE@vc.cvut.cz>
To: viro@math.psu.edu
Cc: linux-kernel@vger.kernel.org, tytso@valinux.com
Subject: 2.4.0-test11 ext2 fs corruption
Date: Tue, 28 Nov 2000 20:32:36 MET-1	[thread overview]
Message-ID: <E2B041435FB@vcnet.vc.cvut.cz> (raw)

Hi Al,
  during weekend I was uncompressing XFree (Debian's 4.0.1-7) at home,
with 2.4.0-test11 running on Celeron 300A, 128MB RAM, SMP kernel on up.
It failed to compile lbxproxy/di/main.c. After some investigation I found
that they were overwritten by some source font data. fsck did not reveal
any croslinked clusters, nothing. Filesystem itself uses 4KB clusters.

  Today I found some spare time and investigated it further. There is
same data contents in:

programs/lbxproxy/di/init.c 0-8720  fonts/bdf/75dpi/lubR24.bdf  0x5000-0x7210
                 lbxfuncs.c 0x0000-0x0EC0           lubR24.bdf  0x8000-0x8EC0
                            0x0EC1-0x0FFF                      zero
                            0x1000-0x5ABC           lutBS08.bdf 0x0000-0x4ABC
                            0x5ABD-0x5FFF                      zero
                            0x6000-0x92C1           lutBS10.bdf 0x0000-0x32C1
                 lbxutil.c  0x0000-0x1E27           lutBS10.bdf 0x4000-0x5E27
                            0x1E28-0x1FFF                      zero
                            0x2000-0x3452           lutBS12.bdf 0x0000-0x1452   
                 main.c     0-4614                  lutBS12.bdf 0x2000-0x3206
                 options.c  0x0000-0x222E           lutBS12.bdf 0x4000-0x622E
                            0x222F-0x2FFF                      zero
                            0x3000-0x4E30           lutBS14.bdf 0x0000-0x1E30
                 pm.c       0-11706                 lutBS14.bdf 0x2000-0x4DA8
             (blocks 722433-722459)                (blocks 558899-~558927)
             
Other files are intouch. As you can see, somewhat disk blocks
ended somewhere else than they should in addition to correct place.
I also found that data after end of file in di/*.c files are not
cleared, so maybe that ide driver did a mistake? But I was not able
to find how to convert either block address, or LBA adress, or CHS
address (drive uses 839/240/63, but I hope that it runs in LBA) to
get 558899 from 722433 or vice versa.

Motherboard is i440BX, HDD was IDE TOSHIBA MK6409MAV on secondary IDE,
running UDMA2.

Nobody complained - neither IDE nor kernel nor ext2, just data were
damaged. Machine does not have any other problems, so I have no idea
what caused this incident. Maybe I stressed MM system too much with
some gnome app during untar?

And last note, according to debian/scripts/source.unpack, programs/lbxproxy
was created first, and fonts/bdf/... was created after that (i.e.
X401src-1 was decompressed first, X401src-2_debian was decompressed
second). This also agrees with zeroed bytes in these datablocks.
                                    Thanks,
                                            Petr Vandrovec
                                            vandrove@vc.cvut.cz

P.S.: Ted, why field 'Blocks: XXX' in debugfs (1.19) is 'Sectors: '
in reality (it reports blocks * 8, so I assume (as I have 4KB clusters)
that it converts it to sector count)?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

             reply	other threads:[~2000-11-28 20:03 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-11-28 20:32 Petr Vandrovec [this message]
2000-11-28 20:02 ` 2.4.0-test11 ext2 fs corruption Alexander Viro
  -- strict thread matches above, loose matches on Subject: below --
2000-11-28 21:10 Petr Vandrovec
2000-11-28 20:04 ` David S. Miller
2000-11-28 20:41 ` Alexander Viro
2000-11-29 16:26   ` Daniel Phillips
2000-11-28 21:46 Petr Vandrovec
2000-11-29  0:43 ` Jens Axboe
2000-11-29  1:08   ` Andrea Arcangeli
2000-11-29  1:11     ` Jens Axboe
2000-11-29  1:32       ` Andre Hedrick
2000-11-29 12:21 schwidefsky
2000-11-29 12:43 ` Alexander Viro
2000-11-29 12:41 Petr Vandrovec

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=E2B041435FB@vcnet.vc.cvut.cz \
    --to=vandrove@vc.cvut.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tytso@valinux.com \
    --cc=viro@math.psu.edu \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox