Read block device linux

Check Linux Block Device with Examples

A block device is a storage device that moves data in sequences of bytes or bits (blocks). These devices support random access and generally use buffered I/O.

Examples include hard disks, CD-ROM drives, and flash drives. A block device can be physically attached to a computer or accessed remotely as if it were physically attached to the computer.

How to use block device on Linux

Device names like /dev/sdh and xvdh are used by Linux systems to describe block devices. The block device mapping is used by the Linux system to specify the block devices to attach to a Linux OS.

After a block device is attached to a host, it must be mounted by the operating system before we can access the storage device. When a block device is detached from a host, it is unmounted by the operating system and we can no longer access the storage device.

How to list block devices on Linux

Use the lsblk command to view our available disk devices and their mount points (if applicable) to help us determine the correct device name to use. The output of lsblk removes the /dev/ prefix from full device paths.

In the following example, the root device is /dev/nvme0n1, which has two partitions named nvme0n1p1 and nvme0n1p128. The attached volume is /dev/nvme1n1, which has no partitions and is not yet mounted.

$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvme1n1 259:0 0 10G 0 disk
nvme0n1 259:1 0 8G 0 disk
nvme0n1p1 259:2 0 8G 0 part /
nvme0n1p128 259:3 0 1M 0 part

How to check if there is a filesystem on the block device

Use the file -s command to get information about a specific device, such as its file system type. If the output shows simply data, as in the following example output, there is no file system on the device

[ ~]$ sudo file -s /dev/xvdf
/dev/xvdf: data

If the device has a file system, the command shows information about the file system type. For example, the following output shows a root device with the XFS file system.

[ ~]$ sudo file -s /dev/xvda1
/dev/xvda1: SGI XFS filesystem data (blksz 4096, inosz 512, v2 dirs)

How to create a filesystem on the block device

If we have an empty volume, use the mkfs -t command to create a file system on the volume.

Warning: Do not use this command if we’re mounting a volume that already has data on it. Otherwise, we’ll format the volume and delete the existing data.

How to get the block device info on Linux

Use the lsblk -f command to get information about all of the devices attached to the instance.

For example, the following output shows that there are three devices attached to the instances—nvme1n1, nvme0n1, and nvme2n1. The first column lists the devices and their partitions.

The FSTYPE column shows the file system type for each device. If the column is empty for a specific device, it means that the device does not have a file system. In this case, device nvme1n1 and partition nvme0n1p1 on device nvme0n1 are both formatted using the XFS file system, while device nvme2n1 and partition nvme0n1p128 on device nvme0n1 do not have file systems.

NAME FSTYPE LABEL UUID MOUNTPOINT
nvme1n1 xfs 7f939f28-6dcc-4315-8c42-6806080b94dd
nvme0n1
├─nvme0n1p1 xfs / 90e29211-2de8-4967-b0fb-16f51a6e464c /
└─nvme0n1p128
nvme2n1

How to mount a block device in Linux

We can use the device name, such as /dev/xvdf, in /etc/fstab, but we recommend using the device’s 128-bit universally unique identifier (UUID) instead.

Device names can change, but the UUID persists throughout the life of the partition. By using the UUID, we reduce the chances that the system becomes unbootable after a hardware reconfiguration.

The fields are the UUID value returned by blkid (or lsblk for Ubuntu 18.04), the mount point, the file system, and the recommended file system mount options.

In the following example, we mount the device with UUID aebf131c-6957-451e-8d34-ec978d9581ae to mount point /data and we use the xfs file system. We also use the defaults and nofail flags. We specify 0 to prevent the file system from being dumped, and we specify 2 to indicate that it is a non-root device.

we need to add the following line to /etc/fstab then run mount /data.

UUID=aebf131c-6957-451e-8d34-ec978d9581ae /data xfs defaults,nofail 0 2

David is a Cloud & DevOps Enthusiast. He has years of experience as a Linux engineer. He had working experience in AMD, EMC. He likes Linux, Python, bash, and more. He is a technical blogger and a Software Engineer. He enjoys sharing his learning and contributing to open-source.

howtouselinux.com is dedicated to providing comprehensive information on using Linux.

We hope you find our site helpful and informative.

Источник

Opening Block Device Files

When a user application opens the device file of a block device, the virtual filesystem invokes the open function of the file_operations structure and arrives at blkdev_open. Figure 6-13 shows the associated code flow diagram.

9Note that this implies that reading data from the block device is already required to work when the device is registered with disk_add!

Figure 6-13: Code flow diagram for blkdev_open.

bd_acquire first finds the matching block_device instance for the device. The pointer to the instance can be read directly from inode->i_bdev if the device has already been used. Otherwise, it is created using the dev_t information. Afterward do_open carries out the main portion of the task, described below. If exclusive access to the block device is requested by setting the flag o_excl, then the block device is claimed with bd_claim. This sets the file instance associated with the device file as current holder of the block device.

Figure 6-14: Code flow diagram for do_open.

The first step of do_open is to call get_gendisk. This delivers the gendisk instance that belongs to the block device. Recall that the gendisk structure describes the partitions of the block device as discussed in Section 6.2.5. However, if the block device is opened for the first time, the information is not yet complete. Nevertheless, the device-specific block_device_operations that are required to work with the device can already be found in the generic hard disk structure.

The kernel then needs to proceed differently depending on the type and state of the block device, as is shown in Figure 6-14. Things are simpler if the block device has been opened before, as can be inferred from the openers count block_device->bd_openers.

□ disk->fops->open invokes the appropriate open function for the file to perform hardware-specific initialization tasks.

□ If the partition information has become invalid as indicated by block_device->bd_invalidated, rescan_partitions is called to re-read the partition information. Partition information can become invalid if a removable medium is exchanged.

If the device has not been opened before, some more work is required. First suppose that not a partition, but the main block device is opened — which may nevertheless contain partitions. In this case, the required actions are modulo some bookkeeping details identical to the case shown above: disk->fops->open handles the low-level work of opening the device, and rescan_partitions reads the partition table if the existing information is invalid.

This is, however, usually the first time that partition information is read in. When a new disk is registered using add_disk, the kernel sets gendisk->bd_invalidated to 1, which signals an invalid partition table on the block device (in fact, since there is no partition table at all, it cannot really be called valid!). Then a fake file is constructed as a parameter passed to do_open, and this, in turn, triggers reading the partition table.

If the opened block device represents a partition that has not been opened before, the kernel needs to associate the block_device instance for the partition with the block_device that contains the partition. Essentially this works as follows:

fs/block_dev.c struct hd_struct *p; struct block_device *whole; whole = bdget_disk(disk, 0);

bdev->bd_contains = whole; p = disk->part[part — 1];

After finding the block_device instance that represents the whole disk that includes the partition, a link between partition and container is set up using block_device->bd_contains. Note that the kernel can find the whole block device starting from the partition’s block device, but not vice versa! Additionally, the partition information in hd_struct is now shared between the generic hard disk and the block_device instance for the partition, as indicated in Figure 6-10.

Related Posts

• Request Queues — Linux Kernel Architecture
• Sectors Blocks and Buffers
• File such as block and character device files FIFOs and even regular files it cannot create directories or sockets though
• Representation of Block Devices
• Block Device Operations — Linux Kernel Architecture
• Devfs Device Files — Linux Kernel Reference
• Get Paid to Write at Home
• Laptop Repair Made Easy
• Computer Repair Mastery Course
• Online Data Entry Jobs
• Search Engine Traffic Guide

Источник