Re: Linux Buffer Cache Does Not Support Mirroring

Jeff V. Merkey (jmerkey@timpanogas.com)
Tue, 02 Nov 1999 14:27:59 -0700


Gerard,

What the hell is this? I wasn't being mean or evil, just tying to
explain. Grow thicker skin and be less sensitive. I think you owe me
an apology.

Jeff

Gerard Roudier wrote:
>
> On Tue, 2 Nov 1999, Jeff V. Merkey wrote:
>
> > Gerard,
> >
> > The Statement relates to increased parallelism on FS code paths (they
> > don't have to block), and allows multiple I/O requests to be handled as
> > a "bundle" rather than one at a time. The benefit is immediately
> > obvious since less time is spent calling semaphore and sync code in the
> > kernel (shorter code paths, less rendudant calling of sync code). There
> > are also benefits for remirroring since disk reqests can now be
> > coalesced into runs and ordered based on block number for elevator
> > seeking. Understand now?
>
> I have reread your previous mail and I had rather to guess than to
> understand what you meant.
>
> As you know, UNIX systems basically implement synchronous IO (wait for
> completion), asynchronous IO (write and don't care) and deferred IO
> (buffer cache). I have been very frustrated in the past when switching
> from VMS to UNIX. I knew for 7 years working on VMS applications the
> vertue of completion callbacks called ASTs on VMS and am currently
> maintaining SCSI drivers that rely on hardware interrupts.
>
> As you can see I have nothing to understand now from you. I just will stop
> considering your postings given your agressivity and your evil way to shit
> on everything that is not what you used to working on in your
> pre-free-software life.
>
> Bye,
> Gérard.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/