Re: File system performance, hardware performance, ext3, 3ware RAID1, etc.

From: Linus Torvalds (torvalds_at_osdl.org)
Date: 02/13/04

  • Next message: Daniel Brahneborg: "2.4.24: "__alloc_pages: 0-order allocation failed"" 
    Date:	Fri, 13 Feb 2004 11:55:16 -0800 (PST)
To: "Eric D. Mudama" <edmudama@mail.bounceswoosh.org>

    On Fri, 13 Feb 2004, Eric D. Mudama wrote:
    >
    > This may be a function of the operating system or the filesystem, but
    > it isn't necessarilly an artifact of the drives themselves. With both
    > read and write caching enabled, random writes will always be faster
    > than random reads from the drive perspective.

    Well.. Yes and no.

    Writes are fundamentally more schedulable, and that's a huge advantage for
    throughput, since latency really doesn't matter. Which means that you'll
    find a lot of loads that can much more easily get to platter speeds for
    writes.

    On the other hand, reads are inherently easier on a pure hardware level,
    since read-ahead and track buffers are trivial ways to get to true platter
    speeds for a lot of reasonable loads.

    And the software-visible 512-byte blocking factor just has to be
    _incredibly_ painful on a hardware level, and I'd be surprised if there
    aren't disks out there already where the actual real physical block-size
    is bigger. Which means that I would expect a lot of drives to internally
    do read-modify-write cycles for small writes.

    And especially in a market where density is often more important than pure
    speed, I'd expect hw manufacturers to have a _huge_ bias towards big
    blocks on the platter, in order to avoid having to have lots of
    inter-sector gaps etc.

    So in that kind of schenario, random writes would be clearly slower than
    random reads.

    > the absolute worst-case write performance should be the same as read
    > performance.

    That is only true if the disk block-size is smaller than the IO blocksize.
    Can somebody fill me in on what modern disks do, especially the
    high-density ones?

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

  • Next message: Daniel Brahneborg: "2.4.24: "__alloc_pages: 0-order allocation failed""

    Relevant Pages

    • windows software raid 0 volume extremely slow
      ... ide channel. ... disks (using 1 such chunk on each of the drives). ... it still shows the same good speeds of 56 and 82 MB/s respectively. ...
      (microsoft.public.windowsxp.hardware)
    • windows software raid 0 volume extremely slow
      ... ide channel. ... disks (using 1 such chunk on each of the drives). ... it still shows the same good speeds of 56 and 82 MB/s respectively. ...
      (microsoft.public.windowsxp.security_admin)
    • Re: Now heres something for FreeBSD advocacy
      ... >reality you will never get over 40MB/s SCSI or not. ... from IBM SCSI drives that surpassed the 'cudas. ... And 'most' disks isn't what you compare. ... >> RAID configuration and you will far exceed the SATA speeds. ...
      (comp.unix.bsd.freebsd.misc)
    • Re: windows software raid 0 volume extremely slow
      ... How is your question even remotely related to Windows Security ... | disks (using 1 such chunk on each of the drives). ... | it still shows the same good speeds of 56 and 82 MB/s respectively. ...
      (microsoft.public.windowsxp.security_admin)
    • Re: Shall I get A8N5X??
      ... sata2 drives will work on sata1 so not too much problem unless you want ... people who seem to think that SATA II drives are actually working at 3Gb/S ... While burst speeds can get up over ... So getting a drive a big 400gib drive that has less platter than other ...
      (alt.comp.periphs.mainboard.asus)