View unanswered posts    View active topics

All times are UTC - 6 hours





Post new topic Reply to topic  [ 8 posts ] 
Print view Previous topic   Next topic  
Author Message
Search for:
PostPosted: Sat Oct 01, 2011 6:54 am 
Offline
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
 Profile  
 
 Post subject:
PostPosted: Sat Oct 01, 2011 8:44 am 
Offline
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
 Profile  
 
 Post subject:
PostPosted: Tue Oct 04, 2011 12:41 pm 
Offline
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... :oops: 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
 Profile  
 
 Post subject:
PostPosted: Tue Oct 04, 2011 10:25 pm 
Offline
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
 Profile  
 
 Post subject:
PostPosted: Wed Oct 05, 2011 12:13 pm 
Offline
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. :D

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
 Profile  
 
 Post subject:
PostPosted: Sat Oct 08, 2011 5:43 am 
Offline
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
 Profile  
 
 Post subject:
PostPosted: Sat Oct 08, 2011 8:32 am 
Offline
Joined: Thu Mar 25, 2004 11:00 am
Posts: 9551
Location: Arlington, MA
Yeah, use mythcommflag in batch mode.
Code:
mythcommflag --rebuild --all


Top
 Profile  
 
 Post subject:
PostPosted: Fri Oct 14, 2011 1:36 pm 
Offline
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
 Profile  
 

Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 8 posts ] 


All times are UTC - 6 hours




Who is online

Users browsing this forum: No registered users and 8 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group

Theme Created By ceyhansuyu