Block, File & Object Storage

Published on:

Most important commands to remember

  • lsblk — inspect the available block-device layers.
  • findmnt -T PATH — find the filesystem serving a path.
  • stat PATH — inspect one filesystem object’s metadata.

Commands and flags

Command or option Meaning
lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS Select device name, device type, capacity, filesystem type, and mount locations.
findmnt -T /etc/hosts Find the mount containing this existing file.
-o SOURCE,FSTYPE,TARGET Show the mount’s source, filesystem type, and mount point.
stat /etc/hosts Show file metadata, including logical size, allocated blocks, ownership, and timestamps.

-o selects output columns in both util-linux commands. Human-readable device capacity and file size in bytes are different presentations; the file’s size is not its filesystem’s free capacity.

The concepts that matter

1. Block storage exposes addressable blocks

A block device provides a range of addresses that software can read and write. A disk, virtual disk, or remote block volume can present this interface. The device does not inherently understand filenames, directories, or users.

Usually a filesystem translates file operations into block operations. A database can also manage storage more directly. Attaching a block volume and mounting a filesystem are therefore separate actions with separate failure modes.

2. File storage exposes paths and filesystem operations

A filesystem organizes data into files and directories, with operations such as opening, reading, renaming, and checking permissions. It can live on local block storage, in memory, or behind a network protocol.

A mount point connects a filesystem into the machine’s path tree. A path does not tell you whether its data is local. The same application file operation may ultimately reach a local disk or a remote file server.

3. Object storage exposes keys and API requests

Object storage addresses objects by keys inside a namespace such as a bucket. An object combines data with metadata, and clients typically use API operations to retrieve or replace it.

A key containing slashes can look like a directory path without having ordinary filesystem directory semantics. Do not assume file-style append, locking, or atomic rename simply because a tool displays folders. The service’s API defines the actual guarantees.

4. The access model matters more than the hardware

The same underlying disks can support block, file, or object services. The difference that an application sees is the interface and its guarantees: what can be updated, how concurrent clients coordinate, and which operations are atomic.

Choose the model around the workload. A filesystem-oriented application needs file semantics; an application storing complete media objects may fit an object API. Performance, durability, and availability still depend on the particular service and configuration.

One small example

Optional: inspect an existing Linux machine. These commands read metadata only and do not attach, format, or mount storage.

lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS
findmnt -T /etc/hosts -o SOURCE,FSTYPE,TARGET
stat /etc/hosts

Use lsblk to distinguish a disk from its partitions or mapped devices. Then use findmnt to identify what actually serves /etc/hosts, and stat to inspect that file rather than the whole storage device.

In a container, /etc/hosts may be a separate bind mount and block devices may be hidden. A network filesystem or an overlay may not map to one obvious lsblk row. That is a useful reminder that a file path and a block device are different layers. This example does not contact object storage.

Keep this idea: Block storage addresses blocks, file storage addresses paths, and object storage addresses keys through an API.