Re: gorged harddrive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2008-04-02 at 12:29 +0800, Ed Greshko wrote:
> Patrick O'Callaghan wrote:
> 
> > Just installed Azureus and tested it. It behaves exactly the same as
> > Ktorrent, both with and without preallocation.
> > 
> > This is hardly surprising as we're talking about how the filesystem
> > works, not about about a specific application. As someone else pointed
> > out, a inconsistency between the results of 'du' and 'df' can occur when
> > a running process has an open file which has been unlinked, meaning the
> > space occupied by the file has not yet been reclaimed even though the
> > file no longer has a name. However, any inconsistency arising from this
> > would be in the *opposite* direction to what the OP is seeing, i.e. less
> > actual free space than accounted for by the filesystem size less the
> > space occupied by (visible) files.
> > 
> > In all of this I've been assuming that preallocation means what it has
> > always meant traditionally in Unix/Linux: write garbage into the file to
> > make sure disk space is allocated. It turns out the system can now do
> > this for you, with the fallocate() call. However this is a very recent
> > addition and people were still arguing about its semantics less than a
> > year ago -- see http://lwn.net/Articles/240571. One detail stands out:
> > with the correct parameter, the apparent size of the file (as reported
> > by the stat() call) does not change, even if space is allocated beyond
> > its end. The effect of this on 'df' and 'du' doesn't seem to be
> > documented anywhere. Furthermore, although it's not explicitly stated,
> > one presumes that the unused space is reclaimed when the file is closed,
> > so the OP's question still stands: how can 'du' report more space than
> > is being used, even if no processes have open files? For that matter,
> > how can the system preallocate more space than the size of the
> > filesystem? Doesn't make sense.
> > 
> > BTW, it might be worth knowing what filesystem the OP is using. In my
> > case it's ext3.
> 
> FWIW, the OP is probably happy to have his problem solved.  Chances are he 
> is running ext3 as most people take the default.
> 
> What would be more interesting would be to know what file system you are 
> running.

ext3, as I already said.

poc

-- 
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux