Patrick O'Callaghan wrote:
On Tue, 2008-04-01 at 10:57 +0800, Ed Greshko wrote:
charles f. zeitler wrote:
--- Ed Greshko <Ed.Greshko@xxxxxxxxxxx> 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@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@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.
