I wrote: > What I’ve read is that the sort of flash you tend to get in these drives > can be very slow for writes, slow to read back data in sequentially, but > they can be a lot faster than hard drives to actually start accessing > the data, because there’s no physical movement required to start reading > from the disk. A quick google resulted in > http://www.tomshardware.com/reviews/security-flash-storage,1804-6.html , > with a couple of drives with access times a tenth of what you’d expect > from a good hard drive, but slower sequential transfer speeds. Aaron Konstam wrote: > Comparing the read rates in that links list for flash drives to the > output of hdparm for hard disks make it clear that disks are faster: > [root@localhost ~]# hdparm -Tt /dev/sda3 > > /dev/sda3: > Timing cached reads: 1630 MB in 2.00 seconds = 815.32 MB/sec > Timing buffered disk reads: 94 MB in 3.01 seconds = 31.20 MB/sec I’m not sure what your point is here, Aaron. For 4K random reads, those speeds are going to be dwarfed by the time it takes to start accessing the data. Firstly, we’re not going to be talking about cached reads. If there was space to cache this data, there would have been no point writing it to swap in the first place. Secondly, my point is that the OS is not going to read in one 4K page, then the next page that happens to be on the disk, then the next. Pages will have been written to the swap file pretty randomly, and then read back in as each process tries to access these pages and page faults. So the OS will be reading 4K at a time from all over the swap file, and won't get a chance to sustain those rates for long. This is true regardless of the media. It’s just that spinning disks are lousy at getting to the point where they can start transferring data. Your figures don’t measure that. Some worked examples might help. Google gave me http://storageadvisors.adaptec.com/2007/03/20/sata-iops-measurement/ which seems reasonable. It suggests that for a 500GB Western Digital SE16 SATA drive (WD5000KS) with a rotation rate of 7200 RPM, it’s going to take around 8.9 ms to get the heads over the right part of the disk.¹ Then there will be another period, waiting for the right part of the disk to come under the disk heads. At 7200 RPM (which is true for nearly all modern desktop disks), the data might be immediately there, or it might need nearly an entire revolution of the disk for the data to be under the read head. (There’s no way a disk going at 7200 RPM will reverse!) But on average, the disk will need to do half a revolution. At 7200 RPM, that’s 60 000 ms / 7200 RPM = 8.3 ms. So you’re likely to be able to get one page off disk every 8.3 ms + whatever fraction of 8.9 ms you think is reasonable + the time to actually get the data off the disk. For a 100 MB/s disk, that would be 100 K/ms, and 4K / 100 K/ms = 0.04 ms. So the transfer time is dominated by the access time. For flash, 30 K/ms gives 4K / 30 K/ms = 0.13 ms. So the flash does transfer the data more slowly. But it can start returning data in around 1 ms, given the figures in the tomshardware link. So it will have finished transferring the data way before the hard disk can start reading the data, in almost all cases. There are a number of caveats to this, and I think I mentioned most of them in my earlier email. James. ¹If you’ve got sustained random reads from a small part of the disk, the head won’t have to move nearly so far. I don’t know how to compensate for that: I don’t believe it’s reasonable to divide by 100 for a 5 GB swap file, because a large part of the access time will be making sure that the head is over exactly the right part of the disk. -- E-mail: james@ | [The Child Support Agency] spent $500M on a computer aprilcottage.co.uk | system from EDS that did not work. The solution? Give EDS | $250M more to fix the broken system. I'm sure we can all | recognise the two simple errors made there. -- Geoff Lane -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
