FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora User

 
 
LinkBack Thread Tools
 
Old 04-02-2008, 04:39 AM
"Patrick O'Callaghan"
 
Default gorged harddrive

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@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 04-02-2008, 04:51 AM
Ed Greshko
 
Default gorged harddrive

Patrick O'Callaghan wrote:


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.


Mis-read it. Sorry....

I run ext3 and it acts as I've said... The output of du and df differ.

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 04-02-2008, 12:22 PM
"Patrick O'Callaghan"
 
Default gorged harddrive

On Wed, 2008-04-02 at 12:51 +0800, Ed Greshko wrote:
> Patrick O'Callaghan wrote:
>
> >>> 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.
>
> Mis-read it. Sorry....
>
> I run ext3 and it acts as I've said... The output of du and df differ.

There's clearly some misunderstanding here, on one side or the other, or
both. Forget it.

poc

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 04-02-2008, 03:13 PM
Ed Greshko
 
Default gorged harddrive

Patrick O'Callaghan wrote:

On Wed, 2008-04-02 at 12:51 +0800, Ed Greshko wrote:

Patrick O'Callaghan wrote:


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.

Mis-read it. Sorry....

I run ext3 and it acts as I've said... The output of du and df differ.


There's clearly some misunderstanding here, on one side or the other, or
both. Forget it.


At least I know exactly what is going on and the OP's issue is resolved. Sure..

--
Crowley was in Hell's bad books. Not that Hell has any other kind.
-- (Terry Pratchett & Neil Gaiman, Good Omens)

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 04-07-2008, 09:58 PM
"Patrick O'Callaghan"
 
Default gorged harddrive

On Wed, 2008-04-02 at 23:13 +0800, Ed Greshko wrote:
> Patrick O'Callaghan wrote:
> > On Wed, 2008-04-02 at 12:51 +0800, Ed Greshko wrote:
> >> Patrick O'Callaghan wrote:
> >>
> >>>>> 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.
> >> Mis-read it. Sorry....
> >>
> >> I run ext3 and it acts as I've said... The output of du and df differ.
> >
> > There's clearly some misunderstanding here, on one side or the other, or
> > both. Forget it.
>
> At least I know exactly what is going on and the OP's issue is resolved. Sure..

I know I said "forget it", but at the risk of beating a dead horse, I'd
just like to share something a friend pointed out, which explains the
OP's original problem.

"du -b" acts differently from "du", and "du -k", and "du -m". The latter
three all give the real disk usage, which for a sparse file will be low
until the file fills up. "du -b" gives the *apparent* file size, which
can indeed be larger than the total filesystem size.

So it all comes down to RTFM ...

poc

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 04-08-2008, 12:56 AM
"Paul Johnson"
 
Default gorged harddrive

On Mon, Apr 7, 2008 at 4:58 PM, Patrick O'Callaghan
<pocallaghan@gmail.com> wrote:
> On Wed, 2008-04-02 at 23:13 +0800, Ed Greshko wrote:
>
>
> "du -b" acts differently from "du", and "du -k", and "du -m". The latter
> three all give the real disk usage, which for a sparse file will be low
> until the file fills up. "du -b" gives the *apparent* file size, which
> can indeed be larger than the total filesystem size.
>
> So it all comes down to RTFM ...
>

I've seen this same trouble with torrent downloads. And I'm not quite
sure about its practical meaning.

In particular, I wonder "How to kill the sparsely filled incomplete
torrent files"?

I'm using the KDE program ktorrent. When you start to download a
bittorrent it creates a bunch of file names and reserves all that
space. When the bit torrent client closes, it leaves behind those file
names even if they are not completed. It seems to me that "du" gives
the reserved space totals, not the actually filled in space. (I don't
use the --apparent-files option). I there any way to know if the
torrent files are downloaded completely?

I'm guessing it is impossible to tell if a file is filled up without
the bit torrent client itself to compare the files. Sometimes the
client itself can't tell.

I have the following problem with the KDE torrent client ktorrent.
When ktorrent starts downloading a torrent, and then the system is
turned off, then re-started, the ktorrent starts to download stuff
again. It downloads the working files to a temporary space, but when
it finishes downloading into the temporary space and it tries to copy
into the finished directory, then it mistakenly thinks that the files
already exist and it asks for new file names. In other words, even
ktorrent is fooled by the "saved space" it marked out when it started
previously. If you give it new file names, it creates them side by
side with the "apparent but really empty" files, and du shows the same
information for them. The only way to tell if the files are real is
to try to load them in a program (in the case of music or video) or
mount (in the case of iso files).

??


--
Paul E. Johnson
Professor, Political Science
1541 Lilac Lane, Room 504
University of Kansas

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 

Thread Tools




All times are GMT. The time now is 02:26 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org