[TAG] 2c tip: filtering in-place

[Ben Okopnik]

On Mon, Mar 22, 2004 at 11:07:44AM -0500, Jay R. Ashworth wrote:
> 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
> > situations.
> 
> 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.
 
AH. I hadn't realized that. In that case, I agree; there's a large
difference. I've just tried it on a 100MB file I've made up for the
purpose, and it seems that you're right.


* Ben Okopnik * okopnik.freeshell.org * Technical Editor, Linux Gazette *
-=-=-=-=-=o0o=-=-=-=-= <http://linuxgazette.net/> =-=-=-=-=o0o=-=-=-=-=-