Author |
Message |
cahlfors
|
Posted: Sat Oct 01, 2011 6:54 am |
|
Joined: Tue Jan 23, 2007 1:38 pm
Posts: 249
Location:
Sweden
|
There is an error in my recordedseek.MYI table somehow, but I am unable to repair it.
I have tried the following:
Code: root@Fido:/var/lib/mysql/mythconverg# myisamchk -r recordedseek.MYI - recovering (with sort) MyISAM-table 'recordedseek.MYI' Data records: 552423 - Fixing index 1 myisamchk: Error writing file '/var/lib/mysql/mythconverg/recordedseek.MYI' (Errcode: 5) myisamchk: error: 5 when fixing table MyISAM-table 'recordedseek.MYI' is not fixed because of errors Try fixing it by using the --safe-recover (-o), the --force (-f) option or by not using the --quick (-q) flag
So then I followed the suggestion using the -o flag instead: Code: root@Fido:/var/lib/mysql/mythconverg# myisamchk -o recordedseek.MYI - recovering (with keycache) MyISAM-table 'recordedseek.MYI' Data records: 2693545 myisamchk: Unknown error 126 myisamchk: error: 126 for record at pos 1502225 myisamchk: error: 5 when trying to write bufferts MyISAM-table 'recordedseek.MYI' is not fixed because of errors Try fixing it by using the --safe-recover (-o), the --force (-f) option or by not using the --quick (-q) flag
And then the -f flag: Code: root@Fido:/var/lib/mysql/mythconverg# myisamchk -f recordedseek.MYI Checking MyISAM file: recordedseek.MYI Data records: 59124 Deleted blocks: 0 myisamchk: warning: Table is marked as crashed and last repair failed - check file-size myisamchk: warning: Size of indexfile is: 73180160 Should be: 1581056 - check record delete-chain - check key delete-chain - check index reference - check data record references index: 1 myisamchk: Unknown error 126 myisamchk: error: Can't read key from filepos: 1575936 - recovering (with sort) MyISAM-table 'recordedseek.MYI' Data records: 59124 - Fixing index 1 myisamchk: Error writing file '/var/lib/mysql/mythconverg/recordedseek.MYI' (Errcode: 5) myisamchk: error: 5 when fixing table MyISAM-table 'recordedseek.MYI' is not fixed because of errors Try fixing it by using the --safe-recover (-o), the --force (-f) option or by not using the --quick (-q) flag
What else can be done?
Thanks,
/Chris
_________________ LinHES R8.6.1 BE: AMD64X4, 4GB, Hauppauge usb tuners FE1: Gigabyte F2A85X-UP4, nVidia GT640 FE2: Gigabyte GA-MA69GM-S2H, AthlonX2 4850E 2.5 GHz, 1GB, ASUS GEFORCE 7200GS 256MB FE3: Asus Eeebox410
|
|
Top |
|
|
tjc
|
Posted: Sat Oct 01, 2011 8:44 am |
|
Joined: Thu Mar 25, 2004 11:00 am
Posts: 9551
Location:
Arlington, MA
|
"Error writing file" sounds like either you're out of disk space or inodes or have a problem with the disk.
Code: df -i df -h
If you can eliminate the first two, then I'd start with an fsck and possibly check for bad blocks.
|
|
Top |
|
|
cahlfors
|
Posted: Tue Oct 04, 2011 12:41 pm |
|
Joined: Tue Jan 23, 2007 1:38 pm
Posts: 249
Location:
Sweden
|
Thanks for rushing to my assistance!
I have made the two first checks with OK results.
Also, I tried to check for bad blocks, but just realize that I spent two days thoroughly badblockchecking the wrong (/myth) filesystem... There were corrections made, but no bad blocks.
A simple fsck on / says it's clean, but an fsck -c -c -v finds 16 inodes with multiply claimed blocks. What would be a proper procedure to deal with these? I have a simple rsync backup, but as it is made with the system running, a restore from it might not produce a startable system in a worst case scenario. Should I try to clone the partition to another disk before letting fsck correct the errors? Or am I being unnecessarily paranoid?
Thanks,
/Chris
_________________ LinHES R8.6.1 BE: AMD64X4, 4GB, Hauppauge usb tuners FE1: Gigabyte F2A85X-UP4, nVidia GT640 FE2: Gigabyte GA-MA69GM-S2H, AthlonX2 4850E 2.5 GHz, 1GB, ASUS GEFORCE 7200GS 256MB FE3: Asus Eeebox410
|
|
Top |
|
|
tjc
|
Posted: Tue Oct 04, 2011 10:25 pm |
|
Joined: Thu Mar 25, 2004 11:00 am
Posts: 9551
Location:
Arlington, MA
|
I would figure out which files were cross linked and focus on them. The problem is that we don't know how long that problem existed or if the backup is good.
|
|
Top |
|
|
cahlfors
|
Posted: Wed Oct 05, 2011 12:13 pm |
|
Joined: Tue Jan 23, 2007 1:38 pm
Posts: 249
Location:
Sweden
|
Hm.
If I understand correctly, letting fsck -c -c -v "correct" the errors by cloning the multiply claimed blocks is a pretty safe procedure. At least, it can't make things worse since it's a mere cloning?
In that process it will tell me which files are affected. I note those and try the database repair procedure again. If it fails, I will know what database files that need recreating from scratch somehow (next challenge...). If I'm lucky, the repair will just succeed this time now that there are no more multiply claimed blocks.
Thanks,
/Chris
_________________ LinHES R8.6.1 BE: AMD64X4, 4GB, Hauppauge usb tuners FE1: Gigabyte F2A85X-UP4, nVidia GT640 FE2: Gigabyte GA-MA69GM-S2H, AthlonX2 4850E 2.5 GHz, 1GB, ASUS GEFORCE 7200GS 256MB FE3: Asus Eeebox410
|
|
Top |
|
|
cahlfors
|
Posted: Sat Oct 08, 2011 5:43 am |
|
Joined: Tue Jan 23, 2007 1:38 pm
Posts: 249
Location:
Sweden
|
Indeed - it worked!
recordedseek.MYI was one of the affected files - quite predictably.
All I need to do now is to reindex all the recordings. It's in here somewhere - I have seen it.
Thanks,
/Chris
_________________ LinHES R8.6.1 BE: AMD64X4, 4GB, Hauppauge usb tuners FE1: Gigabyte F2A85X-UP4, nVidia GT640 FE2: Gigabyte GA-MA69GM-S2H, AthlonX2 4850E 2.5 GHz, 1GB, ASUS GEFORCE 7200GS 256MB FE3: Asus Eeebox410
|
|
Top |
|
|
tjc
|
Posted: Sat Oct 08, 2011 8:32 am |
|
Joined: Thu Mar 25, 2004 11:00 am
Posts: 9551
Location:
Arlington, MA
|
Yeah, use mythcommflag in batch mode.
Code: mythcommflag --rebuild --all
|
|
Top |
|
|
cahlfors
|
Posted: Fri Oct 14, 2011 1:36 pm |
|
Joined: Tue Jan 23, 2007 1:38 pm
Posts: 249
Location:
Sweden
|
It's interesting to note that googling on the matter shows a number of people with the same issue, not necessarily with MythTV, but with MySQL. Another way of solving the problem seems to be copying the damaged table to another place on the hard disk, removing the original and moving the copy back. Essentially, this merely forces a rewrite, likely in a functional location on the disk and does not address any file system or bad block issues.
Thanks,
/Chris
_________________ LinHES R8.6.1 BE: AMD64X4, 4GB, Hauppauge usb tuners FE1: Gigabyte F2A85X-UP4, nVidia GT640 FE2: Gigabyte GA-MA69GM-S2H, AthlonX2 4850E 2.5 GHz, 1GB, ASUS GEFORCE 7200GS 256MB FE3: Asus Eeebox410
|
|
Top |
|
|