I've noticed with the large drives 750gb+ the scans take a while...it looks like they freeze the machine, but if you give it 10 to 20 minutes it eventually completes and mounts properly.

_________________
"The amount of time needed to solve a problem is inversely proportionate to the complexity of the solution" -- Me

KM: R5.5
CPU: Athlon 3800+
Vid: nvidia 7300GT
Snd: Chaintech av-710
Tuner: PVR150
HD: 1000gb sata + 750gb sata + 500gb usb

Yeah I did something to take care of it. I think I ran fsck. Kinda hosed some things (lost my 3rd-party apps and custom shortcuts and customized xorg.conf) and kinda fixed things (my teeny-tiny fonts went back to normal size). Also I took the "opportunity" to switch my connection from DVI/HDMI to VGA, which seems to be a little better with my Vizio 37" LCD tv.

The reason that it lost stuff is most likely because the files in question were cross-linked. (I.e. they contained blocks that were supposedly in multiple files.) The longer you operate in that kind of state the worse the problem can become. Check the lost+found as indicated and you may find something in the recovered fragments there.

I've noticed that most system crashes render errors to the file system. Even if they are repaired promptly, they still seem to have some damage inflicted. I suspect that such a damaged and repaired file system (cross linking, multiply claimed blocks and i-nodes and whatever errors you recovered from) may actually be the cause of new crashes, as they seem to become more and more common, with irreparable errors possibly affecting executables or other essential files.

I've experienced a situation where the sum of the reported sizes using "du" could only account for about half the reported size compared to "df" (which happened to report 100% full...). Most likely this was because of a damaged file system. A restart did not solve the problem in this case.
However, the KnoppMyth way of upgrading with a partition format will take care of any such history in a failsafe way as opposed to the conventional way of upgrading where individual files are replaced. In the latter process, any errors remain unless they are not explicitly overwritten by the upgrade. I think this is the reason that professionals often prefer to use clean installs for production systems rather than upgrading.

Try: and set the parameters to have the root file system checked at every reboot. This will make sure that any file system errors are repaired immediately on discovery. I figure that's the least we can do. Another thing is to activate the SMART disk monitoring feature (simple thing in BIOS, although I think there are Linux tools for it too), so that hard drives with any loss of health can be discovered quickly. *nix systems seem to be picky with bad hard drives.

Cheers,
/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

To my experience, there are two classes of causes for this:
1 - It goes away with a reboot
2 - It does not go away with a reboot

If it goes away with a reboot, then (before the reboot)
"du -xhs /" should show you that there should be room
left, but "df -h /" should say it is used up. and you have
"deleted files that someone still has open". Running
"lsof | grep delete" might show you who (what program)
actually has the files open.

If this does not help then the last page of "du -xk / | sort -n"
may show you where the big files are hiding.

If it does not go away with a reboot then it is one of:
A - Big log files taking up space... this is usually a sign that
something is wrong and you are getting continuous
error messages, although there was a version of KM that
had an issue where it did not clean up (sql?) log files
and even a clean system would eventually run out of
space.
B - Files in lost+found
C - A corrupt file system. A huge journal file created by
a disk corrupting system crash could do this, but I am
not aware that this has actually ever happened.
You can check for this with this (of course replace
sda1 with whatever your root partition is mounted on)
'debugfs -R "stat <8>" /dev/sda1'
D - Recordings stored in the UNMOUNTED /myth directory.
This happened to me. For some reason, one time my
/myth did not mount and so it put the recordings on
sda1 instead of sda3. You can check for this by booting
a Knoppix (yep, Knoppix, not KnoppMyth) disk and seeing
if there is anything in /myth or for that matter in any of
the other mount points.

For A or B the last page of "du -xk / | sort -n" may show you
where the big files are hiding.

I refer you to this thread where I had the issue where it did
not go away on reboot if you are interested:
http://knoppmyth.net/phpBB2/viewtopic.php?t=17915&highlight=

Cliff

_________________
R5F27 using R5F1 Nvidia drivers
HD-5500 analog from NTSC Sat Rx, with OTA DVB too
GeForce MX-440 SVideo tvout to a TV
Older dual core 3.4ghz Intel CPU
Asus P5PE-VM Motherboard
2 GB RAM
1 TB LVM2
VirtualBox
Samba

I don't understand can you solv an example is a little for me please.

Does your "out of space on root partition problem go away
when you do select the "reboot" option from the "knoppmyth"
menu? If so do this the next time you have the problem:
- While holding down the Ctrl and Alt keys, Press the F1 key.
That will get you to a text mode console login screen. For Your
Information, Ctrl-Alt-F7 will get you back to the normal MythTV
screen.
- Log in as root
- (or you can ssh in to the box and use 'sudo su' to get root privilege)
- run
- It prints out a line like this on my good working system
- If this number is above 4.0G then you have normal
log files / lost+found files to clean up and you should
skip down to "Deleting log files".
- else run
- It prints like this on my good working system
- Note that my "Used" column says 2.6G which is pretty close to
the 2.4G I just saw. If it says something above 4.0G and the
'du -xhs /' said something less than 3.5G then you have
hidden/deleted files to find and you should run This will show you what files are pending deletion.
If it is not obvious what to do then post what it says here and
maybe someone can help you with them. Note that it is normal to
have some files in this list. This is what mine looks like:


Deleting log files
- run

This will give you a list of the 50 biggest files and directories on
your root partition. If you know what you are looking at you can
delete some of the files in this list, else post it here for help.

If this is not clear enough then wait till the problem happens again
and post the results of
andand here and ask for help.

Cliff

_________________
R5F27 using R5F1 Nvidia drivers
HD-5500 analog from NTSC Sat Rx, with OTA DVB too
GeForce MX-440 SVideo tvout to a TV
Older dual core 3.4ghz Intel CPU
Asus P5PE-VM Motherboard
2 GB RAM
1 TB LVM2
VirtualBox
Samba

Could you update the DiskFullError page on the wiki with this writeup? The extra information would make a big difference in it's usefulness...

Thanks...