Why doesn't strace show HDD IOCTL syscalls?

Question

When doing an strace -ttT date I miss a lot of syscalls right after the lauch of the executable. After the execve() there are no further syscalls where the date ELF is copied from HDD to memory, does this happen within the kernel? I thought I'd see a lot of IOCTLs to the HDD controller, where each byte gets loaded to memory blockwise?

16:00:00.505197 execve("/bin/date", ["date"], [/* 30 vars */]) = 0 <0.038088>
16:00:00.543671 brk(0)                  = 0x11b9000 <0.000074>
16:00:00.543915 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) <0.000077>
16:00:00.544187 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0f4083a000 <0.000076>
16:00:00.544416 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) <0.000018>
16:00:00.544543 open("/etc/ld.so.cache", O_RDONLY) = 3 <0.000059>

Answer 1

Simplifying a bit, that would be the business of the VFS kernel subsystem, not the userland app.

For all we know that data might live on memory-mapped file system, or on NFS, etc. etc., so kernel shields users from all the complexity, and gives us this handy "file" abstraction, which is just a path over single-rooted directory tree and bunch of attributes, and a set of operations (system calls) to apply (yes, very much the original OO :).

On the system internals side, the file is usually delivered into in-kernel page cache by appropriate FS driver while, or even before, your app blocks in read(2) or something.