Storage functionality provides access to various persisted storage devices as flash memory, SSD and legacy hard disks via files and directories of files.

The file system provides an abstraction to organize the information into separate pieces of data (called files) identified by a unique name. Each file system type defines their own structures and logic rules used to manage these groups of information and their names. Linux supports a plethora or different file system types, local and remote, native and from other operating systems. To accommodate such disparity the kernel defines a common top layer, the virtual file system (VFS) layer.

Summary of the Linux kernel's storage stack

Files and directories

Four basic files access system calls:

• man 2 open ↪ do_sys_open _id - opens a file by name and returns a file descriptor - fd. Below functions operates on a fd.
• man 2 close ↪ close_fd _id
• man 2 read ↪ ksys_read _id
• man 2 write ↪ ksys_write _id

File in Linux and UNIX is not only physical file on persistent storage. File interface is used to access pipes, sockets and other pseudo-files.

🔧 TODO

• man 2 readlink , man 2 symlink , man 2 link
• man 3 readdir ⇾ man 2 getdents
• man 7 path_resolution

⚲ Asynchronous I/O

• https://lwn.net/Kernel/Index/#Asynchronous_IO
• man 2 io_submit man 2 io_setup man 2 io_cancel man 2 io_destroy man 2 io_getevents
• uapi/linux/aio_abi.h _inc
• fs/aio.c _src

Uring - 🌱 New since release 5.1 in May 2019

• https://blogs.oracle.com/linux/an-introduction-to-the-io_uring-asynchronous-io-framework
• https://thenewstack.io/how-io_uring-and-ebpf-will-revolutionize-programming-in-linux/
• io_uring_enter _id io_uring_setup _id io_uring_register _id
• linux/io_uring.h _inc
• uapi/linux/io_uring.h _inc
• fs/io_uring.c _src
• https://lwn.net/Kernel/Index/#io_uring
• io_uring, SCM_RIGHTS, and reference-count cycles
• The rapid growth of io_uring
• Automatic buffer selection for io_uring
• Operations restrictions for io_uring
• io_uring, SCM_RIGHTS, and reference-count cycles
• Redesigned workqueues for io_uring

Logical file systems

A file system (or filesystem) is used to control how data is stored and retrieved. Without a file system, information placed in a storage area would be one large body of data with no way to tell where one piece of information stops and the next begins. By separating the data into individual pieces, and giving each piece a name, the information is easily separated and identified. Each group of data is called a "file". The structure and logic rules used to manage the groups of information and their names is called a "file system".

There are many different kinds of file systems. Each one has different structure and logic, properties of speed, flexibility, security, size and more. Some file systems have been designed to be used for specific applications. For example, the ISO 9660 file system is designed specifically for optical discs.

File systems can be used on many different kinds of storage devices. Each storage device uses a different kind of media. The most common storage device in use today is a SSD. Other media that was used are hard disk, magnetic tape, optical disc, and . In some cases, the computer's main memory (RAM) is used to create a temporary file system for short-term use. Raw storage is called a block device.

Linux supports many different file systems, but common choices for the system disk on a block device include the ext* family (such as ext2, ext3 and ext4), XFS, ReiserFS and btrfs. For raw Flash without a flash translation layer (FTL) or Memory Technology Device (MTD), there is UBIFS, JFFS2, and YAFFS, among others. SquashFS is a common compressed read-only file system.

⚲ Shell interfaces:

• cat /proc/filesystems
• ls /sys/fs/

Infrastructure ⚲ API function register_filesystem _id registers structs file_system_type _id and stores them in linked list ⚙️ file_systems _id. Function ext4_init_fs _id registers ext4_fs_type _id. Operation of file system opening is called mounting: ext4_mount _id

⚙️ Internals

• linux/buffer_head.h _inc
  • super_block _id
  • sb_bread _id
• fs _src
  • fs/ext4/ext4.h _src
    • ext4_sb_bread _id

📚 References

• filesystems _doc

Page cache

A page cache or disk cache is a transparent cache for the memory pages originating from a secondary storage device such as a hard disk drive. The operating system keeps a page cache in otherwise unused portions of the main memory, resulting in quicker access to the contents of cached pages and overall performance improvements. The page cache is implemented by the kernel, and is mostly transparent to applications.

Usually, all physical memory not directly allocated to applications is used by the operating system for the page cache. Since the memory would otherwise be idle and is easily reclaimed when applications request it, there is generally no associated performance penalty and the operating system might even report such memory as "free" or "available". The page cache also aids in writing to a disk. Pages in the main memory that have been modified during writing data to disk are marked as "dirty" and have to be flushed to disk before they can be freed. When a file write occurs, the page backing the particular block is looked up. If it is already found in the page cache, the write is done to that page in the main memory. Otherwise, when the write perfectly falls on page size boundaries, the page is not even read from disk, but allocated and immediately marked dirty. Otherwise, the page(s) are fetched from disk and requested modifications are done.

Not all cached pages can be written to as program code is often mapped as read-only or copy-on-write; in the latter case, modifications to code will only be visible to the process itself and will not be written to disk.

⚲ API:

• man 2 fsync ↪ do_fsync _id
• man 2 sync_file_range ↪ ksys_sync_file_range _id
• man 2 syncfs ↪ sync_filesystem _id

📚 References

• wb_workfn _id
• address_space _id
• do_writepages _id
• linux/writeback.h _inc
• mm/page-writeback.c _src
• Page cache

More

• The future of DAX - direct access bypassing the cache
• Linux Page Cache in Linux Kernel 2.4 Internals

Zero-copy

Writing data to storage and reading are very resource consuming operations. Copying memory is time and CPU consuming operation too. Set of methods to avoid copying operations is called zero-copy. The goal of zero-copy methods is a fast and efficient data transfer within the system.

The first and simplest method is anonymous pipe, invoked by operator "|" in shells. Instead of writing data into temporary file and reading, the data is passed efficiently via a pipe bypassing a storage.

⚲ API and ⚙️ Internals.

• man 2 pipe2 ↪ do_pipe2 _id - creates pipe
  • uses pipe_fs_type _id, pipefifo_fops _id
  • Pipes API _doc
  • fs/pipe.c _src

The second method is tee, available in user space via utility man 1 tee.

• man 2 tee ↪ do_tee _id- duplicates pipe content
  • calls link_pipe _id

Other methods:

• man 2 sendfile ↪ do_sendfile _id - transfers data between file descriptors, the output can be a socket. Used in network storage and servers.
  • Calls: do_splice_direct _id, splice_direct_to_actor _id

• man 2 copy_file_range ↪ vfs_copy_file_range _id - transfers data between files
  • calls custom remap_file_range _id like nfs42_remap_file_range _id
  • or custom copy_file_range _id like fuse_copy_file_range _id
  • or do_splice_direct _id

• man 2 splice ↪ do_splice _id - splices data to/from a pipe.

There are three cases regarding which end being a pipe:

1. do_splice_from _id - only input is a pipe
   • Calls iter_file_splice_write _id or custom splice_write _id
   • or default_file_splice_write _id: write_pipe_buf _id, splice_from_pipe _id, __splice_from_pipe _id
2. do_splice_to _id - only output is a pipe.
   • Calls generic_file_splice_read _id or custom splice_read _id
   • or default_file_splice_read _id: kernel_readv _id
3. splice_pipe_to_pipe _id - both are pipes

• man 2 vmsplice ↪ do_vmsplice _id- splices user pages to a pipe,

🔧 TODO: zerocopy_sg_from_iter _id builds a zerocopy skb datagram from an iov_iter. Used in tap_get_user _id and tun_get_user _id.

skb_zerocopy _id

skb_zerocopy_iter_dgram _id

📚 References

• man 7 pipe
• man 7 fifo
• splice and pipes _doc
• linux/splice.h _inc
• fs/splice.c _src
• splice (system call)
• LTP: pipe _ltp, pipe2 _ltp, tee _ltp, sendfile _ltp, copy_file_range _ltp, splice _ltp, vmsplice _ltp

Block device layer

Linux storage is based on block devices.

Block devices provide buffered access to the hardware, always allowing to read or write any sized block (including single characters/bytes) and are not subject to alignment restrictions. They are commonly used to represent hardware like hard disks.

⚙️ Internals.

• register_blkdev _id
• linux/genhd.h _inc
• block _src
• drivers/block _src
• drivers/scsi _src
• drivers/mtd _src

📚 References

• Block devices _doc
• https://lwn.net/Kernel/Index/#Block_layer
• LDD3:Block Drivers
• LDD1:Loading Block Drivers
• ULK3 Chapter 14. Block Device Drivers

Storage drivers

🔧 TODO

⚙️ Internals

• drivers/ata _src
• drivers/scsi _src
• drivers/nvme _src
• drivers/virtio _src
• drivers/sdio _src