[TAG] 2c tip: filtering in-place
Jay R. Ashworth
jra at baylink.com
Mon Mar 22 19:07:44 MSK 2004
On Mon, Mar 22, 2004 at 11:05:41AM -0500, Ben Okopnik wrote:
> On Mon, Mar 22, 2004 at 11:21:52AM +0530, Kapil Hari Paranjape wrote:
> > As far reading and writing to pipes is concerned, here is how I
> > understand it---please correct me if I am wrong. The kernel has its
> > own *internal* settings on how much data is buffered before a writing
> > process is put at the back of the queue and the reading process is woken
> > up. Thus killing any one process in the "dd" pipeline could only result
> > in *less* data being written than was read---an error from which one can
> > recover as described above.
> Since the source and the target file are the same, wouldn't you end up
> with some truncated version of your data (i.e., the source being gone no
> matter what)? It seems to me that the difference between complete
> destruction of data and truncation of it at some random point can only
> matter theoretically, except in a vanishingly small number of
No, you wouldn't.
The target side dd is doing *random access*.
It writes the blocks sequentially, but it writes them *into* the
standing file, one at a time, without touching the blocks around them.
Likewise on the read side. The killer is the *redirection*, which his
approach does not use, at all. Not the pipe.
Jay R. Ashworth jra at baylink.com
Member of the Technical Staff Baylink RFC 2100
The Suncoast Freenet The Things I Think
Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274
"They had engineers in my day, too." -- Perry Vance Nelson
More information about the TAG