How to deal with file system and snapshot space size inconsistencies

This article introduces how to deal with the inconsistent size of the file system and snapshot space, and focuses on the specific steps. The content of this article is compact, and I hope everyone can gain something.

Why are the file system and snapshot space sizes inconsistent?

A user consulted and found that the snapshot capacity did not become smaller after deleting files in the ECS instance and then taking a snapshot. The reason for this phenomenon is related to the principle of snapshots and the relationship between the file system, the disk, and snapshots. That is, as long as the storage block (Block) of data has been written, the data block will still be deleted even if the related files in the disk have been deleted. Recorded to the snapshot, so the snapshot takes up more space than the disk. The so-called deletion in the file system only marks the header of the file that needs to be deleted to let the user know that this space can be used, but it will not reduce the space occupied by the disk itself.

Why are the file system and snapshot space sizes inconsistent?

What the user sees inside the instance is the disk (EBS), and what is created on the disk partition is the file system (File System). The file system is responsible for managing disk space, and its operations are ultimately converted into disk I/O requests. EBS will record the status of blocks (which refers to the disk's logical block address being divided into blocks of the same size by block storage) and copy dirty data to OSS on demand. This is the process of taking a snapshot.

The following reasons may cause the file system space to be inconsistent with the snapshot size:

The metadata of the file system itself will occupy disk space.

The process of creating a file system will write a large number of Blocks. In particular, the slow formatting of Windows will write a large number of dirty blocks, while using fast formatting can reduce the number of written blocks.

In order to reduce overhead, the file system only marks the file internally when deleting it. However, EBS does not perceive this deletion instruction and the block is still allocated, so this part will still be included in the snapshot, resulting in The snapshot is larger than the file system.

Virtio-block and Xen's Block-front and other modules do not support the TRIM instruction (an IO instruction that prompts a certain piece of data on the LBA to be no longer used and can be deleted), so the disk cannot sense that the data can be deleted. delete.

Principle of creating a snapshot

The principle of creating a snapshot is shown in the figure below.

Instructions:

Divide the disk LBA (logical block address) into Blocks, and the unallocated ones are called empty blocks, which are represented by the small white boxes in the figure.

As long as Block has been written (allocated and will no longer be an empty block), it will participate in measurement.

The first snapshot of the disk is the full volume, and empty blocks are not copied.

The subsequent snapshot of the disk is an incremental snapshot, copying the incremental dirty data since the previous snapshot, so the same Block may have multiple versions in different snapshots (indicated by different colors in the figure).

Snapshot measurement method

As shown in the figure above, there are 11 blocks in the snapshot recording space. There are 2 more blocks out of the 9 in disk T2.

Measure all snapshots of a single disk as a whole.

Only allocated Blocks are measured. The same version of Block at different points in time is only counted once.

Different versions of Block occupy N times the space.

The principle of deleting a snapshot

The principle of deleting a snapshot is shown in the figure below.

Description:

Offline analysis of all blocks of deleted snapshots, and delete the data that is not referenced by other snapshots.

After deleting S1, the remaining snapshots have a total of 10 Blocks (including 6 from S0, 2 dirty data generated by S1, and 2 from S2.) instead of 8 Blocks (6 from S0 , 2 of S2).

Accurate definition of "data write operation"

First clarify a concept, the underlying distribution For traditional storage systems, "data writing operations" not only mean business data written by users, but also include a series of I/O operations such as formatting disks.

After the user gets the disk, it must be formatted before it can be used normally. The essence of formatting is the process of establishing a file system. Before a partition or disk can be used as a file system, it needs to be initialized and the data structure recorded on the disk. This process is called establishing a file system.

Therefore, establishing a file system on the disk means writing data to the disk. Different file systems have different file sizes when formatting. The details are as follows:

Windows system formatting is divided into fast and normal formatting:

Quick formatting only assigns a file system to the partition and rewrites the directory table;

Normal formatting not only performs the above work, but also scans the partition sector by sector to determine and mark bad sectors. ;

Therefore, normal formatting operation will fill the empty blocks of the disk, which is equivalent to writing the entire disk. In this case, the size of the first full snapshot will be approximately the disk capacity. The actual space occupied by quick format is relatively small.

Linux system formatting is also the process of establishing a file system. Therefore, when the disk has just been formatted and the user has not written business data, the first snapshot will also have a certain capacity, depending on the different file system formats.

The above is the detailed content of How to deal with file system and snapshot space size inconsistencies. For more information, please follow other related articles on the PHP Chinese website!