0 bytes on HD

NoOp glgxg at sbcglobal.net
Mon Apr 9 00:22:45 UTC 2012


On 04/08/2012 08:01 AM, Jim Byrnes wrote:
> On 04/08/2012 08:42 AM, J wrote:
>> On Sun, Apr 8, 2012 at 09:08, Nils Kassube<kassube at gmx.net>  wrote:
>>>> Would rebooting allow the 4.7GiB to be recognized as available or is
>>>> a reboot just asking for trouble at this stage?
>>>
>>> See above - probably it wouldn't help but it wouldn't make it worse
>>> either.
>>
>> Actually, this could help quite a bit.  I've noticed that when running
>> out of disk space, evne deleting large numbers of stuff will result in
>> the same behaviour until a reboot.  What happes is that you may delete
>> unnecessary files, and while the inodes are freed up, the tables may
>> not be.  Rebooting will reset the data the system has regarding
>> exactly what inodes are free and what are in use, thus that "free"
>> space will become "available" again.
>>
>> FWIW, I have a problem with xsession-errors being filled silently to
>> the point of filling up my HDD... I've actually had a 120GB
>> xsession-errors file before.  Deleting that one file, because of it's
>> size, resulted in exactly the behaviour described in the OP, where df
>> would tell me I had 120GB free, but 0 available,until a reboot.  And I
>> haven't found a manual way of resetting that.  TIme was, running sync
>> may have helped the kernel catch up to the actual state of the
>> filesystem, but it didn't help in my case, so a strait up reboot
>> worked wonders.
>>
> 
> Thanks, for the reply. I have rebooted and now have 3.2MiB free.  See my 
> reply to Nils for details.  Now I am trying to trace down 29GiB I move 
> to trash but some how never showed up there and is still eating up my 
> disk space.

Now that you have 3.2MiB free - install ncdu (its only 94.2kB installed.

$ sudo apt-get ncdu
$ ncdu

That will show you the directory sizes largest to smallest. See 'man
ndcu' for additional options. You can also get help by entering a
question mark '?' when in ncdu.

What do you show for the following:

$ df -h

and

$ sudo du /var | sort -nr | head -10

/var/backup was the issue directory with SBackup. Maybe the same with
your backup program?

Note: you can do the last on temp & root as well, just change '/var' to
whatever else you want.

Also double check your ~/.gvfs directory to see if there is anything
there. Sometime back there were issues with .gvfs





More information about the ubuntu-users mailing list