gorged harddrive

Ed Greshko Ed.Greshko at greshko.com
Tue Apr 1 12:50:36 UTC 2008


Patrick O'Callaghan wrote:
> On Tue, 2008-04-01 at 10:57 +0800, Ed Greshko wrote:
>> charles f. zeitler wrote:
>>> --- Ed Greshko <Ed.Greshko at greshko.com> wrote:
>>>
>>>> charles f. zeitler wrote:
>>>>> i've been pruning my "downloads" disk,
>>>>> rather drastically, and not making a dent.
>>>>>
>>>>> today some more, less drastic but still
>>>>> hefty, same result.
>>>>>
>>>>> revisited du- checked it twice - three
>>>>> times- yup, it reports one directory at
>>>>> 800+ gb- on a 400gb disk!
>>>>>
>>>>> fsck (forced) failed to report any problems,
>>>>> there don't seem to be any symlinks,
>>>>> and the sub-direcory sizes are sane...
>>>>>
>>>>> any ideas welcome, and appreciated.
>>>> Instead of telling people what you are seeing it would be better to show the 
>>>> actual commands and output.
>>>>
>>> good point.
>>>
>>>
>>> [fedora_8 at Nyarlethotep ~]$ df
>>> Filesystem           1K-blocks      Used Available Use% Mounted on
>>> /dev/sda8             13250836  11459264   1107608  92% /
>>> /dev/sda9              1898468    825572    974904  46% /tmp
>>> /dev/sda11           270882768 259964688   5414052  98% /home
>>> /dev/sda10             1898468   1156484    643992  65% /var
>>> /dev/sdc1            480719056 370452080 105383136  78% /home/fedora_8/music_vids
>>> /dev/sda2               101105     17986     77898  19% /boot
>>> tmpfs                  1037552       248   1037304   1% /dev/shm
>>> /dev/sdb1            384578164 330445976  34596748  91% /home/fedora_8/torrents_isos
>>>
>>> /dev/sdb1 is the drive under discussion.
>>>
>>>
>>> [fedora_8 at Nyarlethotep ~]$ du -sb t*s/*
>>> 34256010522     torrents_isos/backup
>>> 883393808812    torrents_isos/data
>>> 58352749159     torrents_isos/finished
>>> 75197043648     torrents_isos/finnished
>>> 18222558607     torrents_isos/isos
>>> 4781438 torrents_isos/logs
>>> 16384   torrents_isos/lost+found
>>> 4096    torrents_isos/lost_meta
>>> 193903286       torrents_isos/meta
>>> 1402434610      torrents_isos/new
>>> 75585799469     torrents_isos/porn
>>> 4096    torrents_isos/rar
>>> 1318803 torrents_isos/shas
>>> 4096    torrents_isos/tmp
>>> 97996487        torrents_isos/total_meta.tar.bz2
>>> 4096    torrents_isos/zip
>>>
>>> somethings wrong with t*s/data  ....
>>>
>> OK....  I believe I know what the problem is.  The torrents_isos/porn 
>> directory makes things seem larger than what they really are....
>>
>> No, just kidding.....
>>
>> I believe you may have a bunch of non-completed torrent downloads.  When you 
>> start a torrent download the client will reserve the space and it will be 
>> reflected in the output of "du" but *not* in the output of "df".  Thus with 
>> "du" you can have a situation where it "thinks" more disk space is being 
>> used than it actually is.  FWIW, this is normal.
> 
> No.

What do you mean "no"?

When starting the download of a torrent the output of "du" shows the disk 
space has been used.  But, in reality, it hasn't.  df reflects that is 
hasn't been actually used.


> If the space is reserved then it's used and du will see it. Otherwise
> not. Try it and see. Don't be fooled by the apparent size of the
> torrent, that's just the inode information. 'du' exists precisely
> *because* the apparent inode size may be different from the real disk
> usage because of sparse allocation, which BT uses to download sections
> of the file out of sequence.

Somehow I think you are sayihng/agreeing with what I've already said.




More information about the users mailing list