Re: Very low disk performance on 5.x

From: asym (bsdlists_at_rfnj.org)
Date: 05/02/05

  • Next message: Steven Hartland: "Re: Very low disk performance on 5.x" 
    Date: Mon, 02 May 2005 10:48:44 -0400
To: Arne QW=F6rner=22?= <arne_woerner@yahoo.com>

    At 10:38 5/2/2005, Arne "Wörner" wrote:
    >--- Allen <bsdlists@rfnj.org> wrote:
    > > Scenario B, verified read enabled:
    > > 1. RAID card reads up ALL blocks in the stripe (5 reads).
    > > 2. RAID card pretends the block requested is on a "degraded"
    > > drive, and
    > > calculates it from the other 3 + the XOR stripe.
    > > 3. RAID card reports the value back, or tosses some kind of
    > > error.
    > >
    > > You can see, the cache just doesn't play a part in what I was
    > > describing,
    > > which is basically the array performing as though it is degraded
    > > when in
    > > fact it is not, to catch failures that would otherwise be
    > > missed.
    > >
    >That would be a funny implementation. Step one could be done
    >mostly from cache in case of sequential reads from a device (like
    >/dev/ad0s1f or so). In this thread we always looked at sequential
    >reads, as far as I recall...

    It's not "funny" it's just something some people do to try to catch more
    errors.

    RAID5 will not catch transient write errors by default. If there was say
    noise on the bus, and so the wrong value was written to the disk after the
    XOR was performed, but the right XOR data was written to the disk.

    RAID5 would normally never catch such an error, unless you run it in a
    verified mode where it always behaves as though it is degraded, which is
    what I was describing.

    Why you would, I'm not sure. It would catch the errors I suppose, but
    there's nothing it can do about them -- it can't know if the XOR data or
    the actual data is corrupt. Detection without correction is better than
    nothing though, and if performance isn't your real goal, you can turn on
    such features in some cards.

    _______________________________________________
    freebsd-performance@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-performance
    To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org"

  • Next message: Steven Hartland: "Re: Very low disk performance on 5.x"

    Relevant Pages

    • PROBLEM: sata_sil24 lockups under heavy i/o
      ... a total of 4) and started heavy i/o (extending a software raid5 device) ... system recovers the disk transfer speed is reduced from UDMA/100 to ... Cache Line Size: 32 bytes ... parport_pc: Current parallel port base: 0x378 ...
      (Linux-Kernel)
    • Re: Very low disk performance on 5.x
      ... >>I presume you would only compare read to write performance on a RAID5 ... >>device which has battery backed cache. ... results in marginally improved write speeds, ... to make sure the data it read off the disk ...
      (freebsd-performance)
    • Re: Caching control
      ... |> | invalidate/unmap them in order to discard the data from memory. ... |> writing out to disk. ... | easy to discard as clean disk cache. ... stating that a specific amount of RAM can be used only for I/O ...
      (comp.os.linux.development.system)
    • Re: Scheduler: Process priority fed back to parent?
      ... Mac OS X has a special cache ... on disk of things that get loaded on boot. ... >>initial priority is a guess, and isn't set until the priority info has ... This prefetch activity could be turned on/off ...
      (Linux-Kernel)
    • Re: Pull request for FS-Cache, including NFS patches
      ... Would a disk cache on SSD make any sense? ... including NFS patches ... Allow you to reduce the latency of slow network links by diverting ...
      (Linux-Kernel)