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

Re: `du' control files



Hi,
>>"Charles" == Charles Briscoe-Smith <cpbs@debian.org> writes:

Charles> In article <[🔎] 871zx7gyr1.fsf@tiamat.datasync.com>, Manoj
Charles> 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?

Charles> You're not making sense...  The purpose of having the du file
Charles> is specifically because du's output is -independent- of your
Charles> local mount-point strategy.

	In other words, you are not summing any data, and there is a
 line for every file. Why should this information not be provided in
 the *.list files? IS a separate du file the best place for it?

 [example of using the du data deleted]

Charles> - The du file is -very- small.  For strn, the strn.list file
Charles> generated by dpkg takes up 8 disk blocks; the strn.du file
Charles> takes only 1.

	How long does it take to generate it on the fly?
        User time (seconds): 0.03
        System time (seconds): 0.12
        Percent of CPU this job got: 13%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 0:01.13

Charles> Even for tetex-extra, which has a 100 block
Charles> tetex-extra.list file and a 158 block tetex-extra.md5sums
Charles> file, the tetex-extra.du file I just generated for it is only
Charles> 8 blocks in size.  Anyone who's -so- worried about the bloat
Charles> introduced by du files that they'd prefer them not to be
Charles> there should probably hack dpkg to code its <package>.list
Charles> files using frcode, which reduces tetex-extra.list from 158
Charles> blocks to just 19 (see "info find data data new" for more
Charles> info...) or using gzip.

	How long does this take to generate on the fly? 
        User time (seconds): 0.19
        System time (seconds): 1.30
        Percent of CPU this job got: 14%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 0:10.17

Charles> The point of using the `du'-style output is that it gives
Charles> useful information regardless of where your mount points are.
Charles> Of course, I'd expect a competent package manager to also
Charles> scout out all the directories mentioned in the du file to
Charles> stat() them and check their device numbers, in case any
Charles> `directories' were actually symlinks.  For example, I have a
Charles> symlink:

	How is it directly useful?

	manoj

	
-- 
 Excitement and danger await your induction to tracer duty!  As a
 tracer, you must rid the computer networks of slimy, criminal data
 thieves. They are tricky and the action gets tough, so watch out!
 Utilizing all your skills, you'll either get your man or you'll get
 burned! advertising for the computer game "Tracers"
Manoj Srivastava  <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E


Reply to: