Phillip Susi wrote:
Mark Lord wrote:
Phillip Susi wrote:
Sounds like this is a serious bug in the WD firmware.
For personal systems, yes. For servers, probably not a bug.
Disabling readahead means faster execution queued commands,
since it doesn't have to "linger" and do unwanted read-ahead.
So this bug is a "feature" for random access servers.
And a big nuisance for everything else.
I think you misunderstand the bug. The bug is not that the drive
disables internal readahead; the bug is that host supplied readahead
requests work so horribly. It is a good thing that the drive allows the
host to control the readahead, but something is wrong if the drive's
readahead is WAY better than any the host can perform.
Well, in this case, it has already been determined that switching
to a different Linux I/O scheduler gives back most of the performance.
But the drive can do readahead better than the OS: With the OS,
everything is broken up into discrete requests, whereas with the
drive firmware, it can continuously update it's readahead projections,
even in the midst of a command. So it does have an advantage.
But again, only the WD Raptor seems to have serious problems here.
Other drives cope well with readahead + NCQ just fine.
Cheers
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
