FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 09-21-2011, 03:46 PM
Axel Freyn
 
Default 100% used / file system. Help!

Hi Lisi,
On Wed, Sep 21, 2011 at 04:39:45PM +0100, Lisi wrote:
> On Wednesday 21 September 2011 16:16:31 Stan Hoeppner wrote:
> > On 9/21/2011 9:14 AM, Lisi wrote:
> > > And I have taken in that /var/log is a likely culprit.
> >
> > Not necessarily. On a server /var/log is a likely culprit, but on a GUI
> > workstation I'd think /var/cache or /usr would be more likely, assuming
> > the problem is a hosed/misconfigured program. If the problem is the
> > result of an errant drag/drop the files causing the undue swelling could
> > be in any directory you had/have write access to.
> >
> > # du -s -h /var
> > # du -s -h /var/log
> > # du -s -h /var/cache
> > # du -s -h /var/tmp
> > # du -s -h /lost+found
> > # du -s -h /root
> > # du -s -h /tmp
> > # du -s -h /usr
>
> /var/cache and /usr are 6 G between them, so are certainly not
> small. /var/log is not very big at all. But that still doesn't explain the
> jump. Perhaps I have started doing something differently without realising
> it.
>
> Tux:/home/lisi# du -s -h /var
> 2.9G /var
> Tux:/home/lisi# du -s -h /var/log
> 320M /var/log
> Tux:/home/lisi# du -s -h /var/cache
> 2.3G /var/cache
> Tux:/home/lisi# du -s -h /var/tmp
> 43M /var/tmp
> Tux:/home/lisi# du -s -h /lost+found
> 16K /lost+found
> Tux:/home/lisi# du -s -h /root
> 3.4M /root
> Tux:/home/lisi# du -s -h /tmp
> 120K /tmp
> Tux:/home/lisi# du -s -h /usr
> 3.7G /usr
> Tux:/home/lisi#
For /var/cache: did you clean the package cache? "aptitude clean" might
help... (depending on your configuration it MIGHT be that you have many
old .deb-Archives in /var/cache/apt/archives)
So, if "du -s -h /var/cache/apt/archives" reports something large, this
might be the problem...

Axel


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110921154627.GM2118@axel">http://lists.debian.org/20110921154627.GM2118@axel
 
Old 09-21-2011, 05:47 PM
Lisi
 
Default 100% used / file system. Help!

On Wednesday 21 September 2011 16:46:27 Axel Freyn wrote:
> Hi Lisi,
>
> On Wed, Sep 21, 2011 at 04:39:45PM +0100, Lisi wrote:
> > On Wednesday 21 September 2011 16:16:31 Stan Hoeppner wrote:
> > > On 9/21/2011 9:14 AM, Lisi wrote:
> > > > And I have taken in that /var/log is a likely culprit.
> > >
> > > Not necessarily. On a server /var/log is a likely culprit, but on a
> > > GUI workstation I'd think /var/cache or /usr would be more likely,
> > > assuming the problem is a hosed/misconfigured program. If the problem
> > > is the result of an errant drag/drop the files causing the undue
> > > swelling could be in any directory you had/have write access to.
> > >
> > > # du -s -h /var
> > > # du -s -h /var/log
> > > # du -s -h /var/cache
> > > # du -s -h /var/tmp
> > > # du -s -h /lost+found
> > > # du -s -h /root
> > > # du -s -h /tmp
> > > # du -s -h /usr
> >
> > /var/cache and /usr are 6 G between them, so are certainly not
> > small. /var/log is not very big at all. But that still doesn't explain
> > the jump. Perhaps I have started doing something differently without
> > realising it.
> >
> > Tux:/home/lisi# du -s -h /var
> > 2.9G /var
> > Tux:/home/lisi# du -s -h /var/log
> > 320M /var/log
> > Tux:/home/lisi# du -s -h /var/cache
> > 2.3G /var/cache
> > Tux:/home/lisi# du -s -h /var/tmp
> > 43M /var/tmp
> > Tux:/home/lisi# du -s -h /lost+found
> > 16K /lost+found
> > Tux:/home/lisi# du -s -h /root
> > 3.4M /root
> > Tux:/home/lisi# du -s -h /tmp
> > 120K /tmp
> > Tux:/home/lisi# du -s -h /usr
> > 3.7G /usr
> > Tux:/home/lisi#
>
> For /var/cache: did you clean the package cache? "aptitude clean" might
> help... (depending on your configuration it MIGHT be that you have many
> old .deb-Archives in /var/cache/apt/archives)
> So, if "du -s -h /var/cache/apt/archives" reports something large, this
> might be the problem...

:-)

Tux:/home/lisi# du -s -h /var/cache
37M /var/cache
Tux:/home/lisi#

Thank you!

Lisi


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201109211847.05776.lisi.reisz@gmail.com">http://lists.debian.org/201109211847.05776.lisi.reisz@gmail.com
 
Old 09-21-2011, 09:17 PM
Lisi
 
Default 100% used / file system. Help!

On Tuesday 20 September 2011 20:19:30 Thierry Chatelet wrote:
> If you have a basic fs, then gparted-live should do the job of resizing.

Thanks, Thierry, As I hope you now know, this solved it for me. I clearly
ought to have done that as soon as I had the problem, but I needed your prod.

Lisi


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201109212217.45003.lisi.reisz@gmail.com">http://lists.debian.org/201109212217.45003.lisi.reisz@gmail.com
 
Old 09-21-2011, 09:54 PM
Jörg-Volker Peetz
 
Default 100% used / file system. Help!

Lisi wrote, on 09/21/11 19:47:
> On Wednesday 21 September 2011 16:46:27 Axel Freyn wrote:
>> Hi Lisi,
>>
>> On Wed, Sep 21, 2011 at 04:39:45PM +0100, Lisi wrote:
>>> On Wednesday 21 September 2011 16:16:31 Stan Hoeppner wrote:
>>>> On 9/21/2011 9:14 AM, Lisi wrote:
>>>>> And I have taken in that /var/log is a likely culprit.
>>>>
>>>> Not necessarily. On a server /var/log is a likely culprit, but on a
>>>> GUI workstation I'd think /var/cache or /usr would be more likely,
>>>> assuming the problem is a hosed/misconfigured program. If the problem
>>>> is the result of an errant drag/drop the files causing the undue
>>>> swelling could be in any directory you had/have write access to.
>>>>
>>>> # du -s -h /var
>>>> # du -s -h /var/log
>>>> # du -s -h /var/cache
>>>> # du -s -h /var/tmp
>>>> # du -s -h /lost+found
>>>> # du -s -h /root
>>>> # du -s -h /tmp
>>>> # du -s -h /usr
>>>
>>> /var/cache and /usr are 6 G between them, so are certainly not
>>> small. /var/log is not very big at all. But that still doesn't explain
>>> the jump. Perhaps I have started doing something differently without
>>> realising it.
>>>
>>> Tux:/home/lisi# du -s -h /var
>>> 2.9G /var
>>> Tux:/home/lisi# du -s -h /var/log
>>> 320M /var/log
>>> Tux:/home/lisi# du -s -h /var/cache
>>> 2.3G /var/cache
>>> Tux:/home/lisi# du -s -h /var/tmp
>>> 43M /var/tmp
>>> Tux:/home/lisi# du -s -h /lost+found
>>> 16K /lost+found
>>> Tux:/home/lisi# du -s -h /root
>>> 3.4M /root
>>> Tux:/home/lisi# du -s -h /tmp
>>> 120K /tmp
>>> Tux:/home/lisi# du -s -h /usr
>>> 3.7G /usr
>>> Tux:/home/lisi#
>>
>> For /var/cache: did you clean the package cache? "aptitude clean" might
>> help... (depending on your configuration it MIGHT be that you have many
>> old .deb-Archives in /var/cache/apt/archives)
>> So, if "du -s -h /var/cache/apt/archives" reports something large, this
>> might be the problem...
>
> :-)
>
> Tux:/home/lisi# du -s -h /var/cache
> 37M /var/cache
> Tux:/home/lisi#
>
> Thank you!
>
> Lisi
>
>
But the cleaning of the package cache only removed ~ 2.3 GB. And summing up the
above listed disk usage makes only appr. 10 GB.
So were do the other 20 GB come from?
I would like to see the output of

du -hx --max-depth=1 / | sort -h

--
Best regards,
Jörg-Volker.



--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: j5dmem$em1$1@dough.gmane.org">http://lists.debian.org/j5dmem$em1$1@dough.gmane.org
 
Old 09-21-2011, 10:05 PM
Claudius Hubig
 
Default 100% used / file system. Help!

Stan Hoeppner <stan@hardwarefreak.com> wrote:
>On 9/21/2011 9:14 AM, Lisi wrote:
>
>> And I have taken in that /var/log is a likely culprit.
>
>Not necessarily. On a server /var/log is a likely culprit, but on a GUI
>workstation I'd think /var/cache or /usr would be more likely, assuming
>the problem is a hosed/misconfigured program. If the problem is the
>result of an errant drag/drop the files causing the undue swelling could
>be in any directory you had/have write access to.
>
># du -s -h /var
># du -s -h /var/log
># du -s -h /var/cache
># du -s -h /var/tmp
># du -s -h /lost+found
># du -s -h /root
># du -s -h /tmp
># du -s -h /usr

I have just two further, not yet mentioned, ideas here:

a) try to umount /home and check if there is anything in /home –
normally invisible but nevertheless taking up space!

b) check not only the size of specific directories as given above but
the size of _every_ directory in /:

# cd /; du -shcx *

The "x" option makes du stay on the root filesystem, so it ignores
your /home filesystem (even if it is currently mounted). "c" produces
a grand total, you should check that this is the same as the usage
reported by "df". You might want to sort the output by piping the
result into "sort -h" ("h" for sorting wrt human-readable numbers).

Best regards,

Claudius
--
Sorry never means having your say to love.
Please use GPG: ECB0C2C7 4A4C4046 446ADF86 C08112E5 D72CDBA4
http://chubig.net/ http://nightfall.org



--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110922000509.36d0c0f1@ares.home.chubig.net">http ://lists.debian.org/20110922000509.36d0c0f1@ares.home.chubig.net
 
Old 09-21-2011, 10:18 PM
Jörg-Volker Peetz
 
Default 100% used / file system. Help!

Hi,

Claudius Hubig wrote, on 09/22/11 00:05:
<snip>
> b) check not only the size of specific directories as given above but
> the size of _every_ directory in /:
>
> # cd /; du -shcx *
>
> The "x" option makes du stay on the root filesystem, so it ignores

In this command the "x" is useless since * expands to home and du will list the
disk usage of the home-partition.

As I suggested in another mail, better try something like

du -hx --max-depth=1 / | sort -h

> your /home filesystem (even if it is currently mounted). "c" produces
> a grand total, you should check that this is the same as the usage
> reported by "df". You might want to sort the output by piping the
> result into "sort -h" ("h" for sorting wrt human-readable numbers).
>
> Best regards,
>
> Claudius



--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: j5dnq7$n57$1@dough.gmane.org">http://lists.debian.org/j5dnq7$n57$1@dough.gmane.org
 
Old 09-21-2011, 11:17 PM
Claudius Hubig
 
Default 100% used / file system. Help!

Jörg-Volker Peetz <jvpeetz@web.de> wrote:
>Hi,
>
>Claudius Hubig wrote, on 09/22/11 00:05:
><snip>
>> b) check not only the size of specific directories as given above but
>> the size of _every_ directory in /:
>>
>> # cd /; du -shcx *
>>
>> The "x" option makes du stay on the root filesystem, so it ignores
>
>In this command the "x" is useless since * expands to home and du will list the
>disk usage of the home-partition.
>
>As I suggested in another mail, better try something like
>
> du -hx --max-depth=1 / | sort -h

Of course! Thank you very much for your correction, although

cd /; du -shc *

obviously still works if one wants to include the home directory

Thank you again!

Claudius
--
This is NOT a repeat.
Please use GPG: ECB0C2C7 4A4C4046 446ADF86 C08112E5 D72CDBA4
http://chubig.net/ http://nightfall.org



--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110922011711.2f1e6992@ares.home.chubig.net">http ://lists.debian.org/20110922011711.2f1e6992@ares.home.chubig.net
 
Old 09-22-2011, 05:04 AM
 
Default 100% used / file system. Help!

When I have this problem, it's usually because I have too many kernel
versions. Look in /boot or do

$ dpkg --purge linux-image<esc><esc>

I keep the latest and the previous versions around, although I wait until the
partition's full before culling the older versions, which happens during
update.

--


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87aa9x5fs2.fsf@UlanBator.myhome.westell.com">http://lists.debian.org/87aa9x5fs2.fsf@UlanBator.myhome.westell.com
 
Old 09-22-2011, 11:15 AM
Tom H
 
Default 100% used / file system. Help!

On Thu, Sep 22, 2011 at 1:04 AM, R. Clayton <rvclayton@verizon.net> wrote:
>
> When I have this problem, it's usually because I have too many kernel
> versions. *Look in /boot or do
>
> *$ dpkg --purge linux-image<esc><esc>

If it were "/boot" that were full, maybe. But it's "/" (I think) and a
"/boot" of 30GB would have to have quite a few kernels...

To Lisi: have you found the large files/directories that bumped you up
to 30G? (Do you still care? )


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/CAOdo=SzRe02MykjW6RYN118QxGkBpY_0bP¼4Ozx8ZsWJW-zg@mail.gmail.com
 
Old 09-22-2011, 01:14 PM
Stan Hoeppner
 
Default 100% used / file system. Help!

On 9/21/2011 10:39 AM, Lisi wrote:

On Wednesday 21 September 2011 16:16:31 Stan Hoeppner wrote:

On 9/21/2011 9:14 AM, Lisi wrote:

And I have taken in that /var/log is a likely culprit.


Not necessarily. On a server /var/log is a likely culprit, but on a GUI
workstation I'd think /var/cache or /usr would be more likely, assuming
the problem is a hosed/misconfigured program. If the problem is the
result of an errant drag/drop the files causing the undue swelling could
be in any directory you had/have write access to.

# du -s -h /var
# du -s -h /var/log
# du -s -h /var/cache
# du -s -h /var/tmp
# du -s -h /lost+found
# du -s -h /root
# du -s -h /tmp
# du -s -h /usr


/var/cache and /usr are 6 G between them, so are certainly not
small. /var/log is not very big at all. But that still doesn't explain the
jump. Perhaps I have started doing something differently without realising
it.

Tux:/home/lisi# du -s -h /var
2.9G /var
Tux:/home/lisi# du -s -h /var/log
320M /var/log


This needs to be addressed. I'd say something's wrong if you have 320MB
of log files on a workstation. Find the big one(s) and tell us what
they are. One of your daemons is likely being too chatty with a log
file, blasting it before each logrotate, or logrotate isn't working
properly.



Tux:/home/lisi# du -s -h /var/cache
2.3G /var/cache


This is probably where your web browser is storing its cached files. Go
into browser options and clear the cache. May take a while. Tell us
how much space this frees up.



Tux:/home/lisi# du -s -h /var/tmp
43M /var/tmp
Tux:/home/lisi# du -s -h /lost+found
16K /lost+found
Tux:/home/lisi# du -s -h /root
3.4M /root
Tux:/home/lisi# du -s -h /tmp
120K /tmp
Tux:/home/lisi# du -s -h /usr
3.7G /usr


That's reasonable for /usr.

None of this adds up to 30GB. You've got a file(s) somewhere else in a
subdir of / that's taking up tons of space. Or, you may have a huge
sparse file somewhere that got corrupted, causing the filesystem to
treat it as its full, non-sparse, size.


Did you tar a huge set of files/dirs recently?

Did you create a disk or partition backup to an image file somewhat
recently with some utility? If so, where did you save the image file?
Look in that directory for a very large file, tell us the name and size
of the file. Run these commands on the file:


# du -h -B1 [file]
# ls -h -l [file]

If the sizes are dramatically different then you have a sparse file.
Simply remove this image file. Then unmount the filesystem and run
fsck. Due to your partition/filesystem setup, you'll need to schedule
the fsck at the next reboot.



I'll do some chatting to Google, and then at least reduce the size of anything
that serves no useful, or anyhow necessary, purpose.


I'd trust the list members here more than Google hits, except maybe hits
on Debian Administration. Even in that case many of the Google hits are
very old articles that may no longer apply.


--
Stan


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: 4E7B34A5.1020903@hardwarefreak.com">http://lists.debian.org/4E7B34A5.1020903@hardwarefreak.com
 

Thread Tools




All times are GMT. The time now is 07:04 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org