On Linux (and 1980s era Unixes), a storage device (quite often a disk partition on some hard disk, or on some SSD) is a block device (see this) so is a [sub-]sequence of blocks (which is the basic unit of physical I/O). The physical block size depends on the hardware (old IDE disks had a block size of 512 bytes, new large SATA disks have a block size of 4Kbytes, read Advanced Format wikipage), and when you make a file system (with e.g.
mkfs, see mke2fs(8)) you can specify a logical block size which is a multiple (often a small power of two, including 1) of that physical block size. Read also about logical block addressing.
In the past (think of Sun3 workstations of the 1990s) the disk was made of cylinders with heads organized in sectors (read CHS wikipage), with a sector containing a block. Today, these still remains but are a artificial artefact provided by the hard disk controller (the circuit on the disk itself). In some OSes the block device driver rescheduled and reordered IO requests to minimize disk head movement and rotational latency.
This way a file system can work with any type of storage device (traditional hard disk, SSD, USB flash drive, etc.), and only the device driver for the storage device is changed.
Yes, but the evil is in the details (e.g. read about TRIM and Write Amplification, specific to SSDs). And the details are important, so the actual implementation is less simple than your figure. Read more about file systems (and think of clustered & remote file systems including SMB & NFS; read also about Logical Volume Manager).
Read Operating Systems : Three Easy Pieces (and its persistence part).
Notice that block devices are gone in FreeBSD (actually providing a common abstraction for character and block devices). I suspect that even on Windows the OS knows about partitions, block size, etc (but you should check).