All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ray Olszewski <ray@comarre.com>
To: Heimo Claasen <hammer@revobild.net>, linux-newbie@vger.kernel.org
Subject: Re: how to assess occupied space
Date: Sun, 15 Sep 2002 12:05:11 -0700	[thread overview]
Message-ID: <5.1.0.14.1.20020915114634.022e1470@celine> (raw)
In-Reply-To: <200209151843.g8FIhZPc006695@pegasus.wanadoo.be>

At , Heimo Claasen wrote:
>Thanks for the hints; I didn't know some of the 'du' subtelties.
>(BTW, is 'du' for _disk_ or for _directory_ use ?)

du is a very old Unix command (almost all the 2-character ones are ... they 
date back to 300-baud days, if not to 110). I doubt anyone today knows for 
sure what du originally was intended as a mnemonic for. I'd *guess* "disk 
utilization", but I don't really know either.

[...]
>The question for "space occupied" is particularl important with the
>Zip-disks, and sometimes 'du' or 'df' didn't seem to give reliable
>answers.
>(And in any case to know how much space is left demands some mental gym.)

This description is too vague to troubleshoot, probably even for people who 
have Zip drives. I'm not even sure what you mean by "reliable" -- in my 
professional world, a "reliable" measure is one that is repeatable, but not 
necessarily accurate. By that standard, I'd be astounded if du and df were 
not reliable. (Such a measure is far from useless. If you knew, for 
example, that "df" always underestimated free space by 10%, you could 
easily make use of it ... but that might be the "mental gym" you are 
referring to, I suppose.)

I expect you mean accurate, though ... so I wonder if, for example, you are 
allowing for the reserved-for-root exclusion that df makes. Or even the 
effect of the fact that 1K=1024 (usually), not 1000. These are only 
examples of two possible sources of discrepancies between what you get and 
what you expect, included here to try to make concrete why we need the 
details of a complaint, not just a general lament, if we are to give you 
decent advice.

[...]
>The various package managers give some help, but it's not very
>transparent. After I spent full days on de-installing not needed
>packages (and some notes kept would indicate a considerable volume),
>the final result was only a small diminuation of occupied disk space,
>according to those 'du'/'df's.
>Hmm.

Again, you need to be specific here. My own experience is with the Debian 
package manager, and I find it (I mean apt, not dpkg) is very helpful with 
respect to space utilization issues ... not perfect, but still very good. 
Which distro and "various package managers" are you actually using, and 
what are a couple of examples of inconsistencies between the sizes 
the  package manager reports and the added space de-installing actually 
delivers?


--
-------------------------------------------"Never tell me the odds!"--------
Ray Olszewski					-- Han Solo
Palo Alto, California, USA			  ray@comarre.com
-------------------------------------------------------------------------------

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

  parent reply	other threads:[~2002-09-15 19:05 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-15  0:00 how to assess occupied space Heimo Claasen
2002-09-15 18:51 ` Mike Dresser
2002-09-15 19:05 ` Ray Olszewski [this message]
     [not found] ` <Pine.LNX.4.33.0209151447040.23713-100000@router.windsormac hine.com>
2002-09-15 19:07   ` Ray Olszewski
2002-09-15 19:16     ` Mike Dresser
     [not found]     ` <Pine.LNX.4.33.0209151515110.2321-100000@router.windsormach ine.com>
2002-09-15 19:21       ` Ray Olszewski
  -- strict thread matches above, loose matches on Subject: below --
2002-09-15  0:00 Revobild / Heimo Claasen
2002-09-15  4:40 ` Mike Dresser
2002-09-15 12:12   ` Haines Brown
2002-09-15  5:13 ` Ray Olszewski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5.1.0.14.1.20020915114634.022e1470@celine \
    --to=ray@comarre.com \
    --cc=hammer@revobild.net \
    --cc=linux-newbie@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.