Re: `du' control files
In article <[🔎] 871zx7gyr1.fsf@tiamat.datasync.com>,
Manoj Srivastava <srivasta@datasync.com> wrote:
> Without access to my fstab file, how does it know where my
> file systems are mounted in order to give me the information I need?
You're not making sense... The purpose of having the du file is
specifically because du's output is -independent- of your local
mount-point strategy.
> My /usr file system was getting dangerously full, so I split off
> /usr/lib. If I start installing more kernel packages, I'll probably
> split off /usr/src. I could well have further subdivided /usr/X11R6
> out (as I have on machines at work in the past).
> How can one use the du files easily to tell me when a
> partition is getting dangerously full? Or is du just a warm fuzzy
> feeling thing?
No, and I'll give you an example. Those of your partitions which are
relevant were:
>Filesystem Mounted on
>/dev/hda2 /
>/dev/hda6 /home
>/dev/hda7 /usr
>/dev/hda8 /usr/lib
>/dev/hdd5 /var
Now, suppose you don't have strn installed and you want to install
it. strn's `control' and `du' files are easily accessible in the
control.tar.gz part of the .deb file.
strn's `du' control file [excerpted again]:
348 usr/bin
[...]
422 usr/lib/strn/help
470 usr/lib/strn
2 usr/lib/menu
473 usr/lib
43 usr/man/man1
44 usr/man
[...]
84 usr/doc/strn/examples
114 usr/doc/strn
115 usr/doc
981 usr
14 etc/news/strn
15 etc/news
16 etc
And strn's `control' file says:
Installed-Size: 1017
>From this, we can tell you'll need approximately 473 blocks on /dev/hda8
(/usr/lib), 981-473=508 blocks on /dev/hda7 (/usr) and 1017-981=36 blocks
on /dev/hda2, and it won't need space on any of your other partitions.
Now tell me that that isn't useful information, or that it can't be got
from a -pregenerated- `du' file.
A couple of points:
- Actually, the figure for the root partition isn't quite accurate,
because the "Installed-Size" field counts the control info which goes
under /var/lib/dpkg/info. This could be worked around. Maybe we
would have to include the root directory in the du file (currently
it's edited out by dpkg-geninfo and dh_du, because I thought it was
redundant due to the "Installed-Size" field.) This makes the example
calculation 16 blocks on /dev/hda2 and 20 blocks on /dev/hdd5.
- The du file is -very- small. For strn, the strn.list file generated
by dpkg takes up 8 disk blocks; the strn.du file takes only 1.
Even for tetex-extra, which has a 100 block tetex-extra.list file and
a 158 block tetex-extra.md5sums file, the tetex-extra.du file I just
generated for it is only 8 blocks in size. Anyone who's -so- worried
about the bloat introduced by du files that they'd prefer them not to
be there should probably hack dpkg to code its <package>.list files
using frcode, which reduces tetex-extra.list from 158 blocks to just 19
(see "info find data data new" for more info...) or using gzip.
The point of using the `du'-style output is that it gives useful
information regardless of where your mount points are. Of course, I'd
expect a competent package manager to also scout out all the directories
mentioned in the du file to stat() them and check their device numbers,
in case any `directories' were actually symlinks. For example, I have
a symlink:
/usr/doc -> /home/overflow/usr/doc
A front-end can easily cope with this. For the strn example, it means
that 115 blocks goes on /dev/hda6 (/home), and 508-115=393 blocks goes
on /dev/hda7 (/usr). See how easy it is to work all this out?
The tools to exploit this information aren't here yet, but I -have-
put a fair amount of thought into it, and I'm convinced that this is
data which a future tool could make very good use of.
If you disagree, I'd like to hear why.
--
Charles Briscoe-Smith
White pages entry, with PGP key: <URL:http://alethea.ukc.ac.uk/wp?95cpb4>
PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2
PS: If my messages seem late or out-of-date, it's because I'm
communicating in batch mode via floppy-disk-net!
Reply to: