It explains how files are split into blocks and how the filesystem acts as an abstraction layer between files (seen by applications) and blocks (physically written on disks). It also says why disks are called block devices.
1.1 Splitting Up Files Into Blocks
A block device is a storage media, like a hard disk. You can use ‘blkid’ and ‘fdisk -l’ to show a list of block devices attached to your system.
In the following example, ‘sda’ is a disk with 2 partitions ‘sda1′ and ‘sda2′, and ‘sr0′ is a compact disc.
A filesystem can be created on a partition and also on a whole partitionless disk, as both partition and disk are valid block devices.
blkid /dev/sda1: UUID="5b0e4487-b5aa-4186-81fd-f561308f4cf1" TYPE="swap" /dev/sda2: UUID="ec851750-9854-4227-8898-d5695dbd297e" TYPE="ext3" /dev/sr0: LABEL="VBOXADDITIONS_4.2.16_86992" TYPE="iso9660" fdisk -l Disk /dev/sda: 12.9 GB, 12884901888 bytes 255 heads, 63 sectors/track, 1566 cylinders, total 25165824 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000be060 Device Boot Start End Blocks Id System /dev/sda1 2048 786431 392192 82 Linux swap / Solaris /dev/sda2 * 786432 25165823 12189696 83 Linux
In order to use the hardware efficiently and to increase the addressing limit the disk read and write operations are not processing the data byte by byte. Instead these operations are using a larger unit called a block (also called a sector), which is usually 512 Bytes.
Modern hard disks or SSDs can have internally a bigger block size like 4 or 8 KiB (4096 or 8192 Bytes), called the physical block size, but externally continue to use 512 Bytes for the logical block size to respond to read and write requests.
These blocks will then be used to store your files. If any file is bigger than a logical block then obviously additional blocks will be allocated.
1.2 Filesystem as Abstraction Layer Between Files and Blocks
Some kind of database will be needed to keep track of which blocks are allocated to which files and also to store the directory tree, the directory entries with filenames and all metadata (cf. Journalized Filesystem) of the files. This job is done by the filesystem.
The filesystem is designed to respond to IO requests (read and write) with performance and reliability.
1.3 Incompatibilies Between Filesystems
Normally the application does not care about the type of the underlying filesystem; they just send IO requests to the kernel (or to a userspace driver like FUSE) that handles the corresponding filesystem operations. However some limitations can exist between different filesystems, like UNIX ownerships and permissions that are unsupported on Microsoft’s NTFS or FAT32 filesystem.
These minor incompatibilities between filesystems may become important for some software, eg. a CVS repository on an NTFS filesystem will not work properly regarding permissions.
1.4 Filesystem Block Size
The filesystem uses its own block size, which is typically 4 KiB (4096 Bytes). A bigger filesystem block size requires less metadata for big files (less blocks are allocated) but requires more disk space for small files (e.g. a 1 Byte file stored in a 4096 B block wastes 4095 B). It also increases the addressing limit and helps to reduce the IOPS (Input/Output Operations Per Second) and to improve performance. A smaller block size is wasting fewer bytes but need more metadata.
It is recommended to keep the filesystem block size default value and if it is changed it should be a factor of the logical block size.
We will see later how a block device can be divided in partitions (cf. Undelete on Ext3 / Ext4) of different sizes and how to create a new filesystem on it.