From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1M87tn-0002Cb-HH for garchives@archives.gentoo.org; Sun, 24 May 2009 07:13:35 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DCC56E035C; Sun, 24 May 2009 07:13:33 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id A7D19E035C for ; Sun, 24 May 2009 07:13:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 38A7C655FC for ; Sun, 24 May 2009 07:13:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -2.957 X-Spam-Level: X-Spam-Status: No, score=-2.957 required=5.5 tests=[AWL=-0.358, BAYES_00=-2.599] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYBiTrUE+U8z for ; Sun, 24 May 2009 07:13:24 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 0BAE66562C for ; Sun, 24 May 2009 07:13:23 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1M87tT-0006uF-Nj for gentoo-user@gentoo.org; Sun, 24 May 2009 07:13:15 +0000 Received: from athedsl-375359.home.otenet.gr ([79.131.18.61]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 May 2009 07:13:15 +0000 Received: from realnc by athedsl-375359.home.otenet.gr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 May 2009 07:13:15 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-user@lists.gentoo.org From: Nikos Chantziaras Subject: [gentoo-user] Re: Sparse files and df Date: Sun, 24 May 2009 10:13:09 +0300 Organization: Lucas Barks Message-ID: References: <20090524124207.2bc0bf86@coercion> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: athedsl-375359.home.otenet.gr User-Agent: Thunderbird 2.0.0.21 (X11/20090429) In-Reply-To: <20090524124207.2bc0bf86@coercion> Sender: news X-Archives-Salt: 3701a881-c1c7-4afd-861f-b7d1581a35f8 X-Archives-Hash: 833eb7d512a39897201e10be5024b84d Mike Kazantsev wrote: > Hi, > > Here's a bit of a puzzle for me... > > I've got an 40G LVM partition with empty reiserfs on it. > Then I've started rtorrent using this fs as a storage and added two 50G > torrents to it. > Rtorrent had no problems with the fact that partition is smaller than > either of them and created all the downloaded files as sparse, so that > "du -s --apparent-size" showed 100G. > df reported that fs is still empty. > > Few days passed and some data actually hit the file system. > Knowing that it can't handle that much of data I've downloaded files > selectively, pushing completed ones to another fs, leaving a symlink in > their place. > > df now shows that only 5G is free but "du -s" says that files occupy > 15G and apparent size is 65G. I might be wrong, but here's my take on it: The files you moved won't be deleted until they are closed. That means quiting the torrent client. "du" shows space occupied by files that actually have a filename. The files you deleted are still there if the torrent client still has handles on them; they just lack an entry in the directory and therefore "du" doesn't pick them up, but of course "df" does since it's not looking at files individually but asks the filesystem directly. So I suppose simply quitting the torrent client will result in no more handles pointing at those files and therefore they will finally be deleted by the filesystem. If you don't quit the client, new data will be stored in the "invisible" deleted files rather than in the ones pointed to by the symlinks, resulting in "df" showing less and less free space even though "du" won't agree (and losing the downloaded data too since its stored in the deleted files.)