Re: how to increase space for tmpfs /tmp
On 20120402_234538, Stan Hoeppner wrote:
> On 4/2/2012 9:43 PM, Paul E Condon wrote:
>
> > This is the du command and results:
> > root@gq:/# du -k -s -c /[^pm]* /m[^e]*
>
> > 4 /home
>
> Is your /home empty? Your du command seems to think so. That's hard to
Yes. It was empty at the time at which the du command was run. The
normal contents of /home had been moved to /mpb2. I say where the
/home stuff is in the post to which you replied. When I did the move,
I had no idea that I was going to find this puzzle, but I do recall
thinking that the move went very fast, too fast for there to be much
data in /home.
> believe. It would mean you ever created any users. A newly created
> empty dir has a size of 4KB.
At 4KB per extra user, it would take over 12000 extra users to account
for the missing extra space. I don't think I could have created that
many users and not remember. And I don't remember doing such a wild
thing. And the directories are not there. So I probably didn't do it.
And if they were there, du would have found them and counted them.
>
> > 0 /initrd.img
> > 0 /initrd.img.old
> > 0 /vmlinuz
> > 0 /vmlinuz.old
>
> How are these files occupying 0 KB of disk?
That is part of my problem. The disk seems to be corrupted.
>
> > 20 /mpa2
> > 20 /mpa3
> > 4 /mpb1
>
> Do these 3 dirs you created really only contain 44 KB total?
>
> > Why the disagreement between df and du ? How is it possible?
>
> See the discrepancies above? Your du isn't reflecting reality of what's
Yes, I see them. I made my post because I saw them and wanted help in
explaining them. But how can you conclude that it is du that is wrong?
> on disk. And the issue isn't sparse files as that would cause du to
> show you're full but df would say you have tons of actual on disk free
> space.
>
> It seems clear that your ext3 / filesystem is actually full. You are
All the numbers from du are consistent with my memory of what was on the
disks. A lot of empty space. Only the disk full indication from df is
surprising to me. It is an 80GB disk with Wheezy and no Xwindows or Gnome
on it, and only a skeleton /home. Clearly the info from df and du are
incompatible. Could you explain why you conclude it is du that is wrong?
It is a Wheezy root disk, which in my experience should contain no more
than 5 or 6 GB in my experience.
> actually using 54282104 blocks. Go through your directories manually to
> find the files that are eating up that other 15/16ths of your partition.
Isn't that what du automates? Traversing a directory tree and tallying
the space used. Before this experience I would have trusted running du
far more than any manual operation that I performed. If 15 parts out 16
is stuff that shouldn't be there, I would expect a random peek would
have high probability of seeing the bad stuff immediately. But no,
I don't see anything but stuff that is on pretty much any Debian box.
> Given the space in question, I'd say you may likely have some
> downloaded ISOs, or other large files, probably in your /home/paul/
> directory.
I am quite certain that I have never downloaded .ISOs onto this computer.
I have been using this computer for development and data processing. I burn my CDs
on a different computer. I know how I organize my /home on any computer.
On this computer, the place where I normally put large files is unpopulate,
or, perhaps hidden from view by some strange malfunction. But do you actually
see in what I presented, a reason for choosing to believe the df display and
not believe the du display. What reasoning did you go thru? I'm trying to
learn. And I need help on this.
But just because I'm sure I haven't put large files on this disk,
don't conclude that I have refused to look for them. Because of your
comments, I have looked again. I see nothing that is amiss. Except, of
course, the two programs, df and du don't agree. I suppose I could just
wipe the disk and start over. But I don't want to do that. I'd like to
understand what went wrong so that maybe I can avoid it in future.
Thanks for your comments.
--
Paul E Condon
pecondon@mesanetworks.net
Reply to: