mcneill@eplrx7.UUCP (mcneill) (11/10/88)
In using dd in a pipe such as:
rsh otherhost "tar cbf 512 - ." | dd bs=262144 of=/dev/rst9
I noticed that this does not work, but:
rsh otherhost "tar cbf 512 - ." | dd obs=262144 ibs=262144 of=/dev/rst9
works just fine. I looked at the System V source for dd and saw something
like:
if (bs) ibs = obs = bs;
which leads me to believe that setting bs should do the same thing as
setting both ibs & obs.
Does BSD do something different which makes this feature or did I miss
something in the source.
--
Keith D. McNeill | E.I. du Pont de Nemours & Co.
uunet!eplrx7!mcneill | Experimental Station
(302) 695-7395 | P.O. Box 80357
| Wilmington, Delaware 19880-0357chris@mimsy.UUCP (Chris Torek) (11/10/88)
In article <37@eplrx7.UUCP> mcneill@eplrx7.UUCP (mcneill) writes: >I looked at the System V source for dd and saw something like: > if (bs) ibs = obs = bs; >which leads me to believe that setting bs should do the same thing as >setting both ibs & obs. > >Does BSD do something different which makes this feature or did I miss >something in the source. You missed something in the source. (Caveat: I am guessing that the SV dd is based on the V7 dd.) There is a flag called `fflag' that is set by `bs=' but not by `ibs=' nor `obs='. fflag causes dd to use a `fast' loop, which preserves record boundaries on those files that have records (pipes, sockets, ttys, tapes): while ((n = read(...)) > 0) (void) write(..., n); while in other cases, dd completely fills its input buffer before copying to its output. Yes, the manual makes no attempt to explain this. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
ggs@ulysses.homer.nj.att.com (Griff Smith) (11/10/88)
In article <37@eplrx7.UUCP>, mcneill@eplrx7.UUCP (mcneill) writes: > In using dd in a pipe such as: > rsh otherhost "tar cbf 512 - ." | dd bs=262144 of=/dev/rst9 > I noticed that this does not work, What do you mean by `does not work'? If the output device were /dev/rmt9 you would get lots of short blocks on the tape. I don't know what to expect for /dev/rst9. > but: > rsh otherhost "tar cbf 512 - ." | dd obs=262144 ibs=262144 of=/dev/rst9 > works just fine. I looked at the System V source for dd Which version? There was a complete re-write for Vr3. > and saw something like: > if (bs) ibs = obs = bs; > which leads me to believe that setting bs should do the same thing as > setting both ibs & obs. The documentation in the old manual page is confusing. The bs option has a side-effect of doing a block-for-block copy if no conversions are specified. Output buffers do not necessarily have obs characters in them. If you set ibs==obs without setting bs, on the other hand, you force a byte-by-byte copy that fills each output buffer with obs characters. The next release should have better documentation if AT&T and Sun coordinate properly. > Does BSD do something different which makes this feature or did I miss > something in the source. Both versions should have the same feature. > -- > Keith D. McNeill | E.I. du Pont de Nemours & Co. > uunet!eplrx7!mcneill | Experimental Station > (302) 695-7395 | P.O. Box 80357 > | Wilmington, Delaware 19880-0357 -- Griff Smith AT&T (Bell Laboratories), Murray Hill Phone: 1-201-582-7736 UUCP: {most AT&T sites}!ulysses!ggs Internet: ggs@ulysses.att.com
guy@auspex.UUCP (Guy Harris) (11/11/88)
>I looked at the System V source for dd and saw something like: > > if (bs) ibs = obs = bs; > >which leads me to believe that setting bs should do the same thing as >setting both ibs & obs. > >Does BSD do something different... The BSD "dd" does: if (bs) { ibs = obs = bs; if (conv == null) fflag++; } "fflag" appears, from a quick glance at the code, to make "dd" bypass copying data from its input buffer to its output buffer, and just read stuff into its input buffer and write it from that buffer. The S5R3 "dd", although it has all the V7/BSD "dd" features, doesn't have the "fflag" hack - it may copy stuff more efficiently and thus not bother with that particular fast path. Griff?
ggs@ulysses.homer.nj.att.com (Griff Smith) (11/12/88)
In article <429@auspex.UUCP>, guy@auspex.UUCP (Guy Harris) writes: > The S5R3 "dd", although it has all the V7/BSD "dd" features, doesn't > have the "fflag" hack - it may copy stuff more efficiently and thus not > bother with that particular fast path. Griff? I didn't use the fflag hack. The strategy on the new one is to assume that a simple read-write loop will work until proven otherwise. For otherwise, a large switch selects one of 28 separately coded conversion loops to process each input block. If the fast path isn't suppressed, the conversion dispatch loop falls into this case after doing a `read' (flsh flushes the output buffer): /* Simple copy: no conversion, preserve the input block size */ case COPY: obc = ibc; (void)flsh(); break; The following conditions suppress the fast path: 1) A zero value for the `bs' option 2) Any data conversions other than `swab', `noerror' and `sync'. The V9 Research Unix System version takes this one step further: it uses the fast path if ibs == obs (at least it did the last time I checked). I think this is wrong, it increases the chance that I will write a tape that has the wrong block size; I have to remember to use an ibs that is != obs to force obs to be what I intend. -- Griff Smith AT&T (Bell Laboratories), Murray Hill Phone: 1-201-582-7736 UUCP: {most AT&T sites}!ulysses!ggs Internet: ggs@ulysses.att.com