1. the seek occures whenever you perform random I/O, or when you "jump" between different areas of the disk when doing sequential I/O (i.e. you read from sector X to sector X+1000, and then you want to read from sector Z to sector Z+1000 - this "switch" will require a seek).
2. experience shows that for sequential I/O - the hard disk can give you sustained throughput without doing expensive seek operations. the manufacturer plans the mapping of logical blocks into the physical suface, in order to enable that.
3. regarding bus contention - the fact is, there are several busses used for hard disk I/O - the PCI bus (that normally is not saturated at all, at least not in a home PC) - on which both disk traffic and network traffic flows. then there's the bus of the disk - depending on the disk type and the controller configuration in your machine (e.g. you could have one disk controller conneted to 5 disks - which will compete on this disk bus - or you could have 5 different controllers, each connected to 1 disk - so the disks do not compete on the disk bus - only on the PCI bus - which is quite free normally on a home PC).
the screen controller is usually connected to a separate bus - so it doesn't compete with the disk contorller.
finally, there is contention on the interrupt controller's attention (or CPU's attention) - but due to the usae of DMA to pass the data - this only refers to control traffic - which is scarce.
by the way, disk addressing is normally done in LBA units (logical block address) - and for most disk devices (and SSDs) - an LBA is 512 bytes. the logical addresses don't tell you where the data is physically located on the disk - but *normally* the lower LBAs are on the outer tracks, and the higher LBAs are on the inner tracks - and through from/to the lower LBAs is better then throughput to the higher LBAs (e.g. if a disk gives you about 70MB/second from the lower LBAs - it could go as low as 40MB/second from the highest LBAs).
--guy On 04/24/2013 07:33 PM, Elazar Leibovich wrote:
I'm trying to understand in more depth the handling of physical harddrive io in the linux kernel (from pdflush to the actual filesystem driver). When reading about the matter, I found out I'm missing some information at a more basic level. How a regular hard drive behaves? How is it implemented in the Linux kernel. If I understand that correctly, one can abstract a hard drive as a physical device, which gets (how? By DMA?) A block aligned chunk of bytes (is block size different per device?), an in device coordinates (sector and block offset? Is that different power hard drive type?) And a request whether to read or to write. Then the hard drive will wake up and fulfills your request, and ping you when it's done (with IRQ?). I also assume that the typical hard drive will fullfil at most one request in parallel. Now comes a questions. 1. When does the dreaded 10ms seek occur? Will it definitely occur at every request (so to saturate the HD bus, one must use as large requests as possible)? 2. If (1) is correct, what is the largest the HD can spill without further seeking? 3. Which other things uses the bus the HD uses? What can cause IO contention? I warn you that I'm completely ignorant about this topics, so my questions might be totally idiotic, However I couldn't find a good introduction, and I think that Understanding the Linux Kernel haven't touched those more details. I hope I could get a pointer from the least. Thanks, _______________________________________________ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
_______________________________________________ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
