[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: how to increase space for tmpfs /tmp

Paul E Condon wrote:
> Roger Leigh wrote:
> > 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?

There is no trickery.  The root filesystem is plainly available when
booted into recovery mode.  Simply run the du commands there.

Why do you think it needs trickery?

> 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.

You used 'mv' to move what data?  I looked through your previous
postings but don't see any background on this.  You are moving data?
What data?

> 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

Stop!  Proceed no further.

What are you trying to do here?  Why are you using kpartx here?

What does the kernel say about your partitions:

  cat /proc/partitions

> /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:~# 

All pretty much expected.  What did you expect?  The above is
*exactly* what I would expect to see.

But why are you trying to use kpartx on /dev/sda here?  Stop!  You are
off lost in the woods.  Stay on the trail.  (I could explain the
various uses of kpartx but I don't think it would help so will refrain.)

> 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.

Oh, don't tease us so!  :-)

> Is device-mapper driver a standard part of all Debian kernels?

It is a kernel module.  Modules are only loaded if you need them.  You
don't need this one and so it hasn't been loaded.

> Is df really more to be trusted than du when used on a disk that
> could have become corrupted?

If you suspect disk corruption here (I don't, I think it is fine) then
run fsck on the filesystem.

> 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'?

There are many reasons for disk space to be visible in one context and
invisible in another context.  That isn't unusual at all.

Any disk space under a mounted filesystem is invisible.  But it is
still used disk space.  This can happen when /tmp is used for lots of
files and disk space but then another /tmp is mounted on top of it.
This additional one covers up the one below it.

Any files that have been written to but have been unlinked from the
directory will consume space but be invisible.  This often happens
with log files.  A program writes a log file.  It writes a lot of data
to the log file.  A person sees that and thinks, I will remove the
file.  That is the worst possible thing to do.  Having removed the
file from the directory the program is still writing to it.  Therefore
the disk space used by it is still used by it.  The space will only be
freed up when the program writing to it is killed.  This is all due to
the filesystem using reference counting.  The file is only freed when
all of the file handles to it are reduced to zero.  As long as at
least one file handle points to the file then it cannot be freed.

By reading your messages I think either of these two reasons are very


Attachment: signature.asc
Description: Digital signature

Reply to: