Re: how to increase space for tmpfs /tmp
On 20120403_101348, Roger Leigh wrote:
> On Tue, Apr 03, 2012 at 09:59:39AM +0100, Dom wrote:
> > I'd try bringing the system up in recovery mode, unmount all ext3
> > file systems (except /, obviously) and run the du command again. You
> > might find data that was concealed under the mount points.
>
> It's even possible that it's under /tmp.
Some issues with some suggestions:
1) If the data is actually there, it is obviously on my rootfs (/) which
I obviously can't examine in recovery mode. Or can I examine it by some
trickery that someone will tell about?
2) I used mv to move the data, from past experience I judged the execution
time of mv to be consistent with the same about of data the showed up on
/mpb2 according to du.
3) Stan says that the disk is full and that du is just wrong. I say that
'obviously' the outputs of df and du disagree, and with the possibility
of there being some corruption of magnetic marks of disk, it is difficult
to say which report is closer to the truth. How does one decide? Beyond
choosing the one that better fits ones expectations and desires? (wishful
thinking)
4) I started making proparations to wipe and reinstall on the problem computer.
To do that I was working on an entirely different computer (the one on which I
read my mail). I wanted to clean up some partitioning there. This other computer
is running Squeeze. I installed kpartx, tried to use it, and got a real surprise:
root@big:~# kpartx -l /dev/sda
/proc/misc: No entry for device-mapper found
Is device-mapper driver missing from kernel?
Failure to communicate with kernel device-mapper driver.
sda1 : 0 39061504 /dev/sda 2048
sda2 : 0 39061504 /dev/sda 39063552
sda4 : 0 894738434 /dev/sda 82032638
sda5 : 0 894738432 /dev/dm-2 2
root@big:~#
I have never thought about the question being ask in the error message.
I have no idea what the 'good' answer should be for a Debian built
kernel. I do have backups of all my data and highish speed access to
the internet. Perhaps I should take a deep breath and reinstall all three
of my computers. This course of action will take a long time, and it will
keep me from asking (or answering) questions on this list for a long time.
Is device-mapper driver a standard part of all Debian kernels? Is df
really more to be trusted than du when used on a disk that could have
become corrupted? The original problem computer continues to limp
along. It doesn't issue error messages. But that is hardly a reason
for believing it is all OK. As I understand du, it works by walking
the directory tree and tallying the space used by all the objects that
it finds. The -s option only affects how verbose it is in reporting
what it has found. In other words, if du doesn't find something on a
disk, why should one search manually and expect to find something that
it missed. Maybe I should look for something that absolutely should
not be there and is a clue about what made the disk 'go south'?
Advice?
Comment?
Thanks for reading this.
--
Paul E Condon
pecondon@mesanetworks.net
Reply to: