Unexpected byte: 5 at link: 19464000

Unexpected byte: 5 at link: 19464000

am 11.11.2002 12:25:05 von mmokrejs

Hi,
I apologize posting something what I think I can't reproduce, but I'm
rather sure the table "broke itself". Actually, the timestamp column tell
more, after it's fixed.

I've uploaded to the secrets area Brucella_abortus.tar.bz2.
It' contains as table in the stage after the flush but before repair:

How-To-Repeat:

mysql> check table scop2_data;
+-----------------------------+-------+----------+---------- ----------------------------------------------+
| Table | Op | Msg_type | Msg_text |
+-----------------------------+-------+----------+---------- ----------------------------------------------+
| Brucella_abortus.scop2_data | check | warning | 1 clients is using or hasn't closed the table properly |
| Brucella_abortus.scop2_data | check | error | Unexpected byte: 5 at link: 19464000 |
| Brucella_abortus.scop2_data | check | error | Corrupt |
+-----------------------------+-------+----------+---------- ----------------------------------------------+
3 rows in set (1.86 sec)

mysql> flush tables;
Query OK, 0 rows affected (34.14 sec)

mysql> repair table scop2_data;
+-----------------------------+--------+----------+--------- --------------------------------------+
| Table | Op | Msg_type | Msg_text |
+-----------------------------+--------+----------+--------- --------------------------------------+
| Brucella_abortus.scop2_data | repair | info | Wrong bytesec: 108-32-83 at 19483860; Skipped |
| Brucella_abortus.scop2_data | repair | warning | Number of rows changed from 1688 to 1686 |
| Brucella_abortus.scop2_data | repair | status | OK |
+-----------------------------+--------+----------+--------- --------------------------------------+
3 rows in set (2.16 sec)

mysql>


I'm sure I've seen something similar last week and similar output from REPAIR TABLE.
I'm running mysql-BK20021104-debug version on Linux 2.4.20-pre10-ac1.
--
Martin Mokrejs ,
PGP5.0i key is at http://www.natur.cuni.cz/~mmokrejs
MIPS / Institute for Bioinformatics
GSF - National Research Center for Environment and Health
Ingolstaedter Landstrasse 1, D-85764 Neuherberg, Germany
tel.: +49-89-3187 3683 , fax: +49-89-3187 3585


------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)

To request this thread, e-mail bugs-thread12944@lists.mysql.com
To unsubscribe, e-mail

Re: Unexpected byte: 5 at link: 19464000

am 13.11.2002 11:50:50 von Peter Zaitsev

On Monday 11 November 2002 14:25, Martin MOKREJÅ  wrote:
> Hi,
> I apologize posting something what I think I can't reproduce, but I'm
> rather sure the table "broke itself". Actually, the timestamp column tell
> more, after it's fixed.
>
> I've uploaded to the secrets area Brucella_abortus.tar.bz2.
> It' contains as table in the stage after the flush but before repair:

Thank you for providing this information.

Could you please however tell us what you've been doing with this table before
it was corrupted ? Did not you run Optimize ? Or it was just notmal
delete/insert/update tables.

Also are you stating this table was OK initially ? And you did not have any
unclean shutdowns of the server.

I ask these questions as they are fairly important to isolate the problem.

Also could you please tell me which hardware do you have ?
We're trying to gather this information to see if there is some sort of
hardware/kernel parten in corruption problems.


--
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Peter Zaitsev
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Full-Time Developer
/_/ /_/\_, /___/\___\_\___/ Moscow, Russia
<___/ www.mysql.com M: +7 095 725 4955


------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)

To request this thread, e-mail bugs-thread12974@lists.mysql.com
To unsubscribe, e-mail

Re: Unexpected byte: 5 at link: 19464000

am 13.11.2002 12:13:59 von mmokrejs

On Wed, 13 Nov 2002, Peter Zaitsev wrote:

> On Monday 11 November 2002 14:25, Martin MOKREJÅ  wrote:
> > Hi,
> > I apologize posting something what I think I can't reproduce, but I'm
> > rather sure the table "broke itself". Actually, the timestamp column tell
> > more, after it's fixed.
> >
> > I've uploaded to the secrets area Brucella_abortus.tar.bz2.
> > It' contains as table in the stage after the flush but before repair:
>
> Thank you for providing this information.
>
> Could you please however tell us what you've been doing with this table before
> it was corrupted ? Did not you run Optimize ? Or it was just notmal
> delete/insert/update tables.

Hmm, if the former/previous case, where I have seen this error was NOT
this database.table, then I've never run repair on the tablefile you
have seen. If that was the case (I don't remember, sorry), then I used
repair. Ohh, sorry, you ask "Optimize"? No, I haven't used optimize on
this table. It's fairly new and I'm in the process of computing the data
and storing it in the table. Only insert/update/delete.

>
> Also are you stating this table was OK initially ? And you did not have any
> unclean shutdowns of the server.

The table was created by perl program and then filled by the data, row by
row during time. It takes and 2-3 days on 6 machines running in parallel,
if everythings works. In the meantime, it broke.

There were definitely no unclean shutdowns at all, only some "flush table"
commands issued, no crashes of mysqld. I haven't been manipulating the
database/table on the raw file level.

>
> I ask these questions as they are fairly important to isolate the problem.
>
> Also could you please tell me which hardware do you have ?

Intel Linux PIII, dual CPU, 768MB ram:
Linux 2.4.20-pre10-ac1 #1 SMP Tue Oct 15 21:06:15 CEST 2002 i686 unknown unknown GNU/Linux

Hmm, I've forgotten why I have SMP kernel on this machine, I just have
config file for kernel build ... I might inspect this in any case.

PIIX4: IDE controller at PCI slot 00:04.1
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:pio, hdd:pio
SCSI subsystem driver Revision: 1.00
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.8

aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs

scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.8

aic7880: Ultra Wide Channel A, SCSI Id=15, 16/253 SCBs

Vendor: SEAGATE Model: ST39204LW Rev: 0006
Type: Direct-Access ANSI SCSI revision: 03
(scsi0:A:0): 80.000MB/s transfers (40.000MHz, offset 63, 16bit)
Vendor: SEAGATE Model: ST39175LW Rev: 0001
Type: Direct-Access ANSI SCSI revision: 02
(scsi0:A:1): 80.000MB/s transfers (40.000MHz, offset 15, 16bit)
Vendor: HP Model: C1537A Rev: L708
Type: Sequential-Access ANSI SCSI revision: 02
(scsi0:A:5): 10.000MB/s transfers (10.000MHz, offset 32)
Vendor: PLEXTOR Model: CD-ROM PX-40TS Rev: 1.00
Type: CD-ROM ANSI SCSI revision: 02
(scsi0:A:6): 20.000MB/s transfers (20.000MHz, offset 15)
scsi0:A:0:0: Tagged Queuing enabled. Depth 253
scsi0:A:1:0: Tagged Queuing enabled. Depth 253
Vendor: transtec Model: Rev: 0001
Type: Direct-Access ANSI SCSI revision: 03
(scsi1:A:4): 40.000MB/s transfers (20.000MHz, offset 8, 16bit)
scsi1:A:4:0: Tagged Queuing enabled. Depth 253
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
Attached scsi disk sdb at scsi0, channel 0, id 1, lun 0
Attached scsi disk sdc at scsi1, channel 0, id 4, lun 0
SCSI device sda: 17921835 512-byte hdwr sectors (9176 MB)
Partition check:
sda: sda1 sda2 sda4
SCSI device sdb: 17783240 512-byte hdwr sectors (9105 MB)
sdb: sdb1 sdb2 < sdb5 sdb6 sdb7 >
SCSI device sdc: 1094074368 512-byte hdwr sectors (-539345 MB)
sdc: unknown partition table

Hmm, fdisk says:

Disk /dev/sdc: 255 heads, 63 sectors, 68102 cylinders
Units = cylinders of 16065 * 512 bytes

Device Boot Start End Blocks Id System
/dev/sdc1 1 68102 547029283+ 83 Linux



NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 4096 buckets, 64Kbytes
TCP: Hash tables configured (established 131072 bind 43690)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 256k freed
Adding Swap: 1582360k swap-space (priority -1)
3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
00:0b.0: 3Com PCI 3c905B Cyclone 100baseTx at 0xb400. Vers LK1.1.18-ac
SCSI device sdc: 1094074368 512-byte hdwr sectors (-539345 MB)
sdc: sdc1
SCSI device sdc: 1094074368 512-byte hdwr sectors (-539345 MB)
sdc: sdc1
(scsi1:A:4:0): Locking max tag count at 123
(scsi0:A:0:0): Locking max tag count at 49
(scsi0:A:1:0): Locking max tag count at 49

datadir is /data/mysql/ located on sdc1. We use ext2 on those disks.


> We're trying to gather this information to see if there is some sort of
> hardware/kernel parten in corruption problems.

Please let me know if you need more.

--
Martin Mokrejs ,
PGP5.0i key is at http://www.natur.cuni.cz/~mmokrejs
MIPS / Institute for Bioinformatics
GSF - National Research Center for Environment and Health
Ingolstaedter Landstrasse 1, D-85764 Neuherberg, Germany
tel.: +49-89-3187 3683 , fax: +49-89-3187 3585


------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)

To request this thread, e-mail bugs-thread12975@lists.mysql.com
To unsubscribe, e-mail