[comp.unix.ultrix] More undocumented performance issues with dump

D. Allen [CGL]" <idallen@watcgl.waterloo.edu> (06/09/90)

Dump to stdout (a tape):

    # time dump 0bf 32k - / >/dev/nrmt0h
      DUMP: 11318272 bytes were dumped to Standard Output
      DUMP: Dump is done
    0% real=15:34 usr=0.3 sys=1.6 rd=0 wr=4 mem=92 pg=2 rec=18 sw=0 sig=0 cs=2058

Dump to the same tape directly:

    # time dump 0bf 32k /dev/nrmt0h /
      DUMP: 345 tape blocks were dumped on 1 tape(s)
      DUMP: Dump is done
    0% real=7:16 usr=0.4 sys=1.6 rd=0 wr=4 mem=94 pg=2 rec=18 sw=0 sig=0 cs=2019

I guess there's something dump can figure out from the file name that
it can't figure out with fstat() on the open device.  Too bad.
Better not have any non-standard names for your tapes, I guess.
-- 
-IAN! (Ian! D. Allen) idallen@watcgl.uwaterloo.ca idallen@watcgl.waterloo.edu
 [129.97.128.64]  Computer Graphics Lab/University of Waterloo/Ontario/Canada

D. Allen [CGL]) (06/11/90)

> I guess there's something dump can figure out from the file name that
> it can't figure out with fstat() on the open device.  Too bad.
> Better not have any non-standard names for your tapes, I guess.

This was wrong.  Ultrix dump assumes that any output to stdout is to a
pipe; it doesn't do the same stat() [fstat()] tests to determine device
type that it does when you give the file name on the command line.
-- 
-IAN! (Ian! D. Allen) idallen@watcgl.uwaterloo.ca idallen@watcgl.waterloo.edu
 [129.97.128.64]  Computer Graphics Lab/University of Waterloo/Ontario/Canada