Re: Very low disk performance on 5.x

From: Poul-Henning Kamp (phk_at_phk.freebsd.dk)
Date: 05/02/05

  • Next message: Poul-Henning Kamp: "Re: Very low disk performance on 5.x" 
    To: "Steven Hartland" <killing@multiplay.co.uk>
Date: Mon, 02 May 2005 15:53:34 +0200

    >Interesting stuff so:
    >1. How to we test if this is happening?

    Calculate by hand what the offset of the striped/raid part of the disk
    is (ie: take slice+partition stats into account).

    >2. How do we prevent it from happening?

    Make sure that the first sector of a partition/slice is always the first
    sector in a stripe on your raid/stripe/whatever.

    >3. Why would this be effecting reads and not writes as surely the same
    >blocking is being done for both?

    Write on RAID5 uses a cache which lies to you about when things are
    safely stored on the disk.

    Good RAID5 has battery backup for that cache.

    The MBR slice format is stupid because it more often than not gets
    this exactly wrong. Typically there are 63 "sectors per track" and
    that ruins any alignment in 99% of the cases.

    Sysinstall, fdisk and bsdlabel should know about all this and try
    to help the user get it right. Fixing them to do so may be more
    trouble than writing a better too bottom up. 

    -- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
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

    • Re: Implementing NVMHCI...
      ... writes regardless of how small the cache entry is, ... allocated blocks on disk), but there's a couple of things that should be ... and WNT would likely have exactly the ... and reporting a 16kB sector size to the READ CAPACITY command. ...
      (Linux-Kernel)
    • Re: Can I create a successive file
      ... file data are in successive disk block so I can read them faster. ... If you read a sector and the OS returns it ... read a whole track and cache it, even if you only asked for one of the ... throughput (this "highest" throughput may also be higher in some areas ...
      (comp.unix.programmer)
    • Re: EMC on VMS
      ... The most-obvious problem area is in a shadow copy from a non-EMC disk ... to an EMC disk ... With the non-mirrored cache that EMC has, ... sector could conceivably be damaged beyond the limitations of the ...
      (comp.os.vms)
    • Re: New filesystem for Linux
      ... "Disk that can atomically write one sector so that the sector ... maybe I am completly wrong but as far as I understand no disk currently will provide such requirement. ... That is a reasonable setting for most end users (high performance, few power outages and some risk of data loss), but when data integrity is a hard requirement, people typically run with the write cache disabled. ...
      (Linux-Kernel)
    • Re: SortMerge avoids thrashing (was: Baileys "two pass" FFT algorithm question)
      ... of size that match the backing store to assure locality of reference. ... For RAM backed by disk, the key thing which takes the most time is ... you need to localize sector reads within that one ... Sweeps your RAM once when you load original data from disk. ...
      (comp.programming)