In article <[EMAIL PROTECTED]>, Manoj Srivastava <[EMAIL PROTECTED]> 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!
