Output to block device in linux kernel

[Baruch Even]

On Wed, Apr 24, 2013 at 7:33 PM, Elazar Leibovich <elazarl at gmail.com> 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.
>
> A disk is arranged in sectors, another name used is LBA, normally it is
512 bytes. Some newer HDDs have a native sector size of 4096 bytes (so
called Advanced Format disks). SSDs have native blocks of 4k or 8k and
erase blocks of around 256KB. All of the disks (hdds and ssds) can access
at the 512 sector size but it may be inefficient to do so, the most
efficient way is to use the native sector size or multiples of it aligned
to the native sector size.

Data transfer depends on the bus SATA is one and SAS is another common one
in servers. In any case the controller for that bus will use DMA but you
normally do not need to worry about it unless you write that low level
driver.

> Then the hard drive will wake up and fulfills your request, and ping you
> when it's done (with IRQ?).
>
The hard drive sends the data back on the bus, the controller takes care of
doing the interrupt as needed, it may skip it altogether or batch a few
requests into one interrupt to save cpu time at some expense to latency.

> I also assume that the typical hard drive will fullfil at most one request
> in parallel.
>
Depends. An HDD can handle one read or write request at a time, it can have
quite a few (32 in SATA, 256 in SAS) requests pending and it will reorder
them as it sees fit. An SSD can handle many requests 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)?
>
10ms doesn't happen all the time, it's close to the worst time. You have
two reasons for seek time in an HDD, one is the seek between tracks (in and
out of the disk) and the other is inside the track (the rotation of the
disk). The disk may optimize its accesses to avoid some seeks and some
times it has no choice but to seek.

> 2. If (1) is correct, what is the largest the HD can spill without further
> seeking?
>
I failed to parse the question.

>  3. Which other things uses the bus the HD uses? What can cause IO
> contention?
>
Guy answered that already.

> 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.
>
http://www.scribd.com/doc/37792234/Hard-Disk-Basics

It's an out-of-print book which has a very in-depth explanation of many HDD
concepts.

Baruch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20130424/27db71d4/attachment-0001.html>