On Thu, Apr 05, 2007 at 09:45:52AM -0400, Bill Davidsen wrote: > Iustin Pop wrote: > >On Wed, Apr 04, 2007 at 07:11:50PM -0400, Bill Davidsen wrote: > > > >>You are correct, but I think if an optimization were to be done, some > >>balance between the read time, seek time, and read size could be done. > >>Using more than one drive only makes sense when the read transfer time is > >>significantly longer than the seek time. With an aggressive readahead set > >>for the array that would happen regularly. > >> > >>It's possible, it just takes the time to do it, like many other "nice" > >>things. > >> > > > >Maybe yes, but why optimise the single-reader case? raid1 already can > >read in parallel from the drives when multiple processes read from the > >raid1. Optimising the single reader can help in hdparm or other > >benchmark cases, but in real life I see very often the total throughput > >of a (two drive) raid1 being around two times the throughput of a single > >drive. > > Why optimize the single thread case? Any process which has low CPU > requirements (by current standards) becomes i/o bound. The obvious > candidates are grep, sed, dd, or awk. And don't overlook the benefits of > reliable swap. "Premature optimisation is the root of all evil". Of course it's possible to do it. But is it worth it? In terms of code complexity, of possible bugs, etc. And what do you gain? raid0 performance and mirroring? it's already available in raid10. Reliable swap? Yes, I do that over raid1. But if raid raw I/O speed is the bottleneck, the solution is add more ram instead of optimising raid1. And honestly, I like the raid1 code to be as simple as possible. If you really find grep, sed, dd to be a bottleneck, you need to think if the tools you are using are the right tools. As I said, raid1 shows good read speed if using *more that one process doing I/O at a time*. Two dd's in parallel are using two drives. Iustin - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
