Re: Very low disk performance on 5.x

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

  • Next message: Poul-Henning Kamp: "Re: Very low disk performance on 5.x" 
    Date: Mon, 02 May 2005 09:58:49 -0400
To: "Steven Hartland" <killing@multiplay.co.uk>, "Eric Anderson" <anderson@centtech.com>, "Poul-Henning Kamp" <phk@phk.freebsd.dk>

    At 09:28 5/2/2005, Steven Hartland wrote:
    >----- Original Message ----- From: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
    >>>Wouldn't this be a problem for writes then too?
    >>I presume you would only compare read to write performance on a RAID5
    >>device which has battery backed cache.
    >>Without a battery backed cache (or pretending to have one) RAID5
    >>write performance is abysmall no matter which alignment you use.
    >
    >This not what's been reported we are seeing writes that are 2x the
    >speed of reads. Give the additional overhead that writes encure
    >on RAID5 this should never be the case. The results I go in my tests
    >where:

    FWIW I have exactly this situation on a Mylex controller I have, if I
    enable the write cache on the card. For some reason or another, doing so
    results in marginally improved write speeds, but sustained read speeds that
    drop well below 1/4 of the values they get when the *write* cache is disabled.

    I have never figured out nor discovered a satisfactory explaination for why
    this is the case, and unlike Erics situation, this is consistent for me on
    that card across all OSes and tests. May be some more fuel for the fire
    however, to someone in the know.

    Also you should keep in mind, there could simply be some really goofy
    controller option enabled, that forces the RAID5 to behave in a "degraded"
    state for reads -- forcing it to read up all the other disks in the stripe
    and calculate the XOR again, to make sure the data it read off the disk
    matches the checksum. It's rare, but I've seen it before, and it will
    cause exactly this sort of RAID5 performance inversion. Since the XOR is
    recalculated on every write and requires only reading up one sector on a
    different disk, options that do the above will result in read scores
    drastically lower than writes to the same array.

    _______________________________________________
    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: Poul-Henning Kamp: "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)
    • md: md6_raid5 crash 2.6.20
      ... the drives in the raid5 array starting giving read errors. ... Note I'm using PATA drives on with a promise IDE controller (using the ... CPU: L2 Cache: 512K ... SCSI device sda: 312581808 512-byte hdwr sectors ...
      (Linux-Kernel)
    • Re: Very low disk performance on 5.x
      ... >mostly from cache in case of sequential reads from a device (like ... RAID5 will not catch transient write errors by default. ... but the right XOR data was written to the disk. ...
      (freebsd-performance)
    • Re: Very low disk performance on 5.x
      ... > and calculate the XOR again, to make sure the data it read off ... > cause exactly this sort of RAID5 performance inversion. ... Isn't that compensated by the cache? ... Mail has the best spam protection around ...
      (freebsd-performance)
    • Re: Storage performance questions
      ... >> There seem to be a rumour floating around that RAID5 is just as fast as ... >> RAID0 on the above storage systems. ... This goes against every benchmark I ... > cache, not after it gets destaged to disk. ...
      (comp.unix.solaris)