> > John is perfectly correct, although of course a 10ms seek is a > >fairly slow one. > > Unfortunately it doesn't seem to be. Take a well-considered drive such > as the WD RE3; it's spec for average latency is 4.2ms. However does it > include the rotational latency (the time the head takes to reach the > sector once it's on the track)? I bet it doesn't. Taking it to be only > the average seek time, this drive is still among the fastest. For a > 7200rpm drive this latency is just 4.2ms, so we'd have for this fast > drive an average total latency of 8.4ms. That's an average. For a random seek to exceed that, it's going to have to span many cylinders. Give the container size of a modern cylinder, that's a pretty big jump. Single applications will tend to have their data lumped somewhat together on the drive. > > The biggest question in my mind, however, is why is random access a > >big issue for you? Are you running a very large relational database > with > >tens of thousands of tiny files? For most systems, high volume accesses > >consist mostly of large sequential I/O. > > No, random I/O is the most common case for busy servers, when there > are lots of processes doing uncorrelated reads and writes. Even if a Yes, exactly. By definition, such a scenario represents a multithreaded set of seeks, and as we already established, multithreaded seeks are vastly more efficient than serial random seeks. The 400 seeks per second number for 4 drives applies. I don't know the details of the Linux schedulers, but most schedulers employ some variation of an elevator seek to maximize seek efficiency. The brings the average latency way down and brings the seek frequency way up. > single application does sequential access the head will likely have > moved between them. The only solution is to have lots of ram for > cache, and/or lots of disks. It'd be better if they were connected to > several controllers... A large RAM cache will help, but as I already pointed out, the increases in returns for increasing cache size diminish rapidly past a certain point. Most quality drives these days have a 32MB cache, or 128M for a 4 drive array. Add the Linux cache on top of that, and it should be sufficient for most purposes. Remember, random seeks implies small data extents. Lots of disks will bring the biggest benefit, and disks are cheap. Multiple controllers really are not necessary, especially if the controller and drives support NCQ , but having multiple controllers certainly doesn't hurt. -- 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
