tencent cloud

TencentOS Server

DocumentationTencentOS ServerUser GuideStorage and File SystemsFile System Management

File System Management

Download
Focus Mode
Font Size
Last updated: 2026-10-19 17:22:50
AI-Translated

File System Overview

File System Overview

A file system is a method used by an OS to organize and store data. It establishes a mapping between abstract concepts such as files, directories, and tree-like directory structures and the data blocks on storage devices. Users only need to remember file paths without concerning themselves with the specific storage devices or corresponding data blocks, as the file system manages storage space. Currently, the file systems supported by TencentOS Server mainly include ext4 and xfs.

ext4

ext4 is a journaling file system and an upgraded version of ext3. It was released in Linux 2.6.28 as a fully functional and stable file system. The ext4 file system supports backward compatibility with ext3, a maximum file system size of 1 EiB and a maximum file size of 16 TiB (with 4 KiB block size), up to 64,000 subdirectories, journal checksumming, online defragmentation, and fast file system checking.

xfs

xfs is a high-performance journaling file system that excels at handling parallel I/O. When spanning multiple storage devices, it offers exceptional scalability in I/O threads, file system bandwidth, and file and file system sizes.

Comparison of ext4 and xfs

Limitations

File System Type
Max Filename Length
Path Character Limit
Max Path Length
Max File Size
Max File System Capacity
ext4
255B
Non-NUL characters
No limit
16TiB
1EiB
xfs
255B
Non-NUL characters
No limit
8EiB
8EiB

Metadata

File System Type
File Owner
POSIX File Permission
File creation time
File Last Access Time
File Last Modified Time
Metadata Last Changed Time
Access Control List
Mandatory Access Control (MAC)
Extended Attributes
ext4
Supported
Supported
Supported
Supported
Supported
Supported
Supported
Supported
Supported
xfs
Supported
Supported
Supported
Supported
Supported
Supported
Supported
Supported
Supported

Others

File System Type
Hard Link
Soft link
Block Journal
Metadata Journal
Case Sensitivity
Performs encryption
Scaling
ext4
Supported
Supported
Supported
Supported
Supported
Supported
Supports offline scaling and online expansion.
xfs
Supported
Supported
Supported
Supported
Supported
Not supported.
Supports online expansion only.

Creating a File System

To use a file system, you need to create it first, which is commonly referred to as formatting.
Note:
Creating a file system (formatting) erases all data on the target partition, and the data cannot be recovered. Before proceeding, confirm that the target device is correct and that you have backed up all data you want to keep.

Creating an ext4 File System

Creating an ext4 File System with mkfs.ext4

You can use the mkfs, mkfs.ext4, and mke2fs commands to create an ext4 file system. mkfs serves as the frontend entry point, which invokes the corresponding mkfs.fstype command based on the file system type specified by the -t option. For example, when creating an ext4 file system, the mkfs.ext4 command is ultimately executed. The binary file corresponding to mkfs.ext4 is a hard link to /usr/sbin/mke2fs, so executing mkfs.ext4 actually runs mke2fs.
The mkfs command is as follows:
mkfs -t ext4 block-device
The mkfs.ext4 command is as follows:
mkfs.ext4 block-device
The mke2fs command is as follows:
mke2fs -t ext4 block-device
The following example creates an ext4 file system on the block device /dev/sdb1:
mkfs.ext4 /dev/sdb1

Default Parameters for File System Creation

mkfs.ext4 applies default configurations to the initial file system by reading /etc/mke2fs.conf. The default configurations used by TencentOS Server are as follows:
[defaults]
        base_features = sparse_super,large_file,filetype,resize_inode,dir_index,ext_attr
        default_mntopts = acl,user_xattr
        enable_periodic_fsck = 0
        blocksize = 4096
        inode_size = 256
        inode_ratio = 16384

[fs_types]
        ext3 = {
                features = has_journal
        }
        ext4 = {
                features = has_journal,extent,huge_file,flex_bg,metadata_csum,64bit,dir_nlink,extra_isize
        }
        small = {
                blocksize = 1024
                inode_ratio = 4096
        }
        floppy = {
                blocksize = 1024
                inode_ratio = 8192
        }
        big = {
                inode_ratio = 32768
        }
        huge = {
                inode_ratio = 65536
        }
        news = {
                inode_ratio = 4096
        }
        largefile = {
                inode_ratio = 1048576
                blocksize = -1
        }
        largefile4 = {
                inode_ratio = 4194304
                blocksize = -1
        }
        hurd = {
             blocksize = 4096
             inode_size = 128
             warn_y2038_dates = 0
        }
The configuration file uses multiple sections, with multiple tags listed under each section. Each tag can also define subtags using braces. The sections are described as follows:
Section
Description
[defaults]
Specifies general default parameters, with a lower priority than the same configuration in the [fs_types] section or command line parameters.
[fs_types]
Specifies default parameters for specific file systems or specific usage scenarios (such as small, big, and so on), which can be specified through the -T option of mke2fs.
Others
Additionally, the options and devices sections are supported. For details, see the man page.
The descriptions of common tags are as follows:
Tag
Description
base_features
Basic features enabled by default when the file system is created. TencentOS Server enables sparse_super, large_file, filetype, resize_inode, dir_index, and ext_attr. If multiple configuration items with the same name exist, the last one in the [fs_types] section takes effect.
default_mntopts
Mount options enabled by default when the file system is mounted. TencentOS Server enables acl and user_xattr.
enable_periodic_fsck
Whether to force a periodic file system check at system startup. TencentOS Server defaults to 0 (disabled). When set to 1, a forced check is performed after 180 days of cumulative runtime or after a certain number of cumulative mounts.
blocksize
Default block size of the file system. TencentOS Server defaults to 4096 bytes.
inode_size
Size of an inode. TencentOS Server defaults to 256 bytes.
inode_ratio
Ratio of partition size to the number of inodes (the actual calculation formula may vary). TencentOS Server defaults to 16384.
features
Configuration for enabling or disabling additional file system features. Adding ^ before a feature disables it, while not adding ^ enables it.
ext3
Parameters used when an ext3 file system is created (using an ext4 file system is recommended).
ext4
Parameters used when an ext4 file system is created. TencentOS Server enables has_journal, extent, huge_file, flex_bg, metadata_csum, 64bit, dir_nlink, and extra_isize.
small / floppy / big / huge / news / largefile / largefile4
Preset configurations for specific usage scenarios, corresponding to small file systems, floppy disks, large file systems, larger file systems, newsgroup data, large files, and larger files.
hurd
Configuration for the GNU Hurd OS.
For more configuration details, see man mke2fs.conf.

Specifying File System Creation Parameters via Command Line Options

You can set parameters for file system creation by modifying the /etc/mke2fs.conf configuration file. You can also set default parameters through mkfs.ext4 or mke2fs command line options. The common mke2fs options are described as follows:
-b specifies the block size.
-t specifies the file system type. The mkfs.ext4 command does not require this option, and the mke2fs command creates an ext2 file system by default.
-i specifies the inode_ratio.
-I specifies the inode size.
-O specifies the features of the file system. To disable a feature, add ^ before it.
-T specifies the usage scenario of the file system. Its value is a parameter item listed under fs_types in the /etc/mke2fs.conf configuration.
For more options, see the man page.
The following example creates an ext4 file system on the block device /dev/sdb2, with a block size of 2048 bytes, an inode size of 128 bytes, and the metadata_csum feature disabled.
mkfs.ext4 -b 2048 -I 128 -O ^metadata_csum /dev/sdb2

Creating an xfs File System

To create an xfs file system, use the mkfs or mkfs.xfs command.
The mkfs command is as follows:
mkfs -t xfs block-device
The mkfs.xfs command is as follows:
mkfs.xfs block-device
mkfs is the frontend entry point and ultimately invokes the mkfs.xfs command. The common options of mkfs.xfs are described as follows:
-b block_size_options specifies the file system block size, for example, -b size=4096.
-m global_metadata_options specifies the file system metadata area configuration, for example, -m crc=1.
-d data_section_options specifies the file system data section configuration, for example, -d agcount=4.
-i inode_options specifies the inode section configuration, for example, -i size=512.
The following example creates an xfs file system on the block device /dev/sdb3, with a block size of 4096 bytes, an inode size of 512 bytes, and the crc feature enabled. If a file system already exists on the device, mkfs.xfs refuses to proceed by default, and the -f option is used to force formatting:
mkfs.xfs -b size=4096 -m crc=1 -i size=512 -f /dev/sdb3
For more detailed options, see man mkfs.xfs.

Mounting and Unmounting File Systems

Mounting a File System

Manually Mounting a File System

After the file system is created, it must be mounted to a directory in the system before it can be used.
Mounting a File System by Block Device File Path
You can use the mount command to manually mount a file system. The following example mounts the device /dev/sdb1 to the /mnt directory:
mount /dev/sdb1 /mnt/
Mounting a File System by Block Device UUID
You can also mount a device by UUID. The following example mounts the device with UUID f9ce3b49-da65-4eca-8692-7dafxxxxxxxx to the /data directory:
mount UUID=f9ce3b49-da65-4eca-8692-7dafxxxxxxxx /data
Specifying the File System Type of the Device to Mount
Typically, mount can automatically detect the file system type on a block device. If mount cannot detect it, you can specify the file system type using the -t option. Example:
mount -t xfs /dev/sdb3 /home/test
Specifying Mount Attributes
You can specify mount attributes using the -o option. The following example mounts the file system as read-only:
mount -o ro /dev/sdb2 /data
For more detailed options, see man mount.

Mounting File System Automatically

During system startup, systemd automatically mounts file systems based on the configuration in /etc/fstab.
Example:
/dev/mapper/os-root     /                       ext4    defaults        1 1
UUID=88d0f4bd-bed0-4307-867e-50d02353fea2 /boot                   ext4    defaults        1 2
UUID=08C2-8D97          /boot/efi               vfat    umask=0077,shortname=winnt 0 2
/dev/mapper/os-home     /home                   ext4    defaults        1 2
The configuration file above lists four mount configurations, with each line representing one mount configuration that contains six fields. The fields are described as follows:
Field
Description
Device
Device to mount. You can use a device path or UUID, or a special file system such as proc or a remote file system such as nfs.
Mount Point
Mount point path. For swap, this field is set to none.
File System Type
File system type, such as ext4, xfs, vfat, or swap.
Mount Option
Mount options, such as defaults, ro, or noauto.
dump
The dump utility determines whether to back up the file system based on this field.
fsck Check Order
fsck determines the order of file system checks during system startup based on this field.
Manually run the mount -a command to automatically mount the devices configured in /etc/fstab. Devices with the noauto mount attribute will not be mounted automatically.

Viewing Mount Information

Using mount to View Mount Information

The mount command can display the current mount information of the system, as shown below:
mount
Output example:
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime,seclabel)
...
/dev/mapper/os-root on / type ext4 (rw,relatime,seclabel)
...
From the displayed result, you can see mount information such as mounted devices, mount points, file system types, and mount attributes.

Using lsblk to View Mount Information

You can use lsblk to view the current mount information of the system, as shown below:
lsblk
Output example:
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda           8:0    0   64G  0 disk 
├─sda1        8:1    0   50M  0 part /boot/efi
├─sda2        8:2    0  512M  0 part /boot
└─sda3        8:3    0 63.4G  0 part 
  ├─os-root 253:0    0   30G  0 lvm  /
  └─os-home 253:1    0 33.4G  0 lvm  /home
sdb           8:16   0   64G  0 disk 
├─sdb1        8:17   0    8G  0 part 
├─sdb2        8:18   0    8G  0 part /data
└─sdb3        8:19   0   64M  0 part /home/test
From the displayed result, you can see mount information such as mounted devices, mount points, and file system capacity.

Using the df Command to View Mount Information

You can use df -h to view the system mount information, as shown below:
df -h
Output example:
Filesystem           Size  Used Avail Use% Mounted on
devtmpfs             4.0M     0  4.0M   0% /dev
tmpfs                3.7G     0  3.7G   0% /dev/shm
tmpfs                1.5G  9.2M  1.5G   1% /run
/dev/mapper/os-root   30G  5.4G   23G  20% /
tmpfs                3.7G   16K  3.7G   1% /tmp
/dev/sda2            488M  238M  215M  53% /boot
/dev/sda1             50M  5.5M   45M  11% /boot/efi
/dev/mapper/os-home   33G   12M   31G   1% /home
tmpfs                748M   80K  748M   1% /run/user/1000
tmpfs                748M   28K  748M   1% /run/user/0
/dev/sdb2            7.8G   24K  7.4G   1% /data
/dev/sdb3             60M  4.0M   56M   7% /home/test
From the displayed result, you can see information such as mounted devices, total file system capacity, used space, available space, utilization, and mount points.
You can use df -i to view the inode usage of mounted file systems, as shown below:
df -i
Output example:
Filesystem           Inodes  IUsed   IFree IUse% Mounted on
devtmpfs            1048576    481 1048095    1% /dev
tmpfs                957374      1  957373    1% /dev/shm
tmpfs                819200    898  818302    1% /run
/dev/mapper/os-root 1966080 131563 1834517    7% /
tmpfs               1048576     27 1048549    1% /tmp
/dev/sda2             32768    226   32542    1% /boot
/dev/sda1                 0      0       0     - /boot/efi
/dev/mapper/os-home 2195456    495 2194961    1% /home
tmpfs                191474    102  191372    1% /run/user/1000
tmpfs                191474     31  191443    1% /run/user/0
/dev/sdb2            524288     11  524277    1% /data
/dev/sdb3             32768      3   32765    1% /home/test
From the displayed result, you can see information such as mounted devices, total file system inode quantity, used inode quantity, free inode quantity, inode utilization, and mount points.
For more detailed options, see man df.

Using findmnt to View Mount Information

Use the findmnt command to display system mount information, as shown below:
findmnt
Output example:
TARGET                         SOURCE      FSTYPE     OPTIONS
/                              /dev/mapper/os-root
|                                          ext4       rw,relatime,seclabel
|-/proc                        proc        proc       rw,nosuid,nodev,noexec,relatime
| `-/proc/sys/fs/binfmt_misc   systemd-1   autofs     rw,relatime,fd=31,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,
|   `-/proc/sys/fs/binfmt_misc binfmt_misc binfmt_mis rw,nosuid,nodev,noexec,relatime
|-/sys                         sysfs       sysfs      rw,nosuid,nodev,noexec,relatime,seclabel
| |-/sys/kernel/security       securityfs  securityfs rw,nosuid,nodev,noexec,relatime
| |-/sys/fs/cgroup             cgroup2     cgroup2    rw,nosuid,nodev,noexec,relatime,seclabel,nsdelegate,memory_recur
| |-/sys/fs/pstore             pstore      pstore     rw,nosuid,nodev,noexec,relatime,seclabel
...
|-/boot                        /dev/sda2   ext4       rw,relatime,seclabel
| `-/boot/efi                  /dev/sda1   vfat       rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,s
|-/home                        /dev/mapper/os-home
|                                          ext4       rw,relatime,seclabel
| `-/home/test                 /dev/sdb3   xfs        rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquot
`-/data                        /dev/sdb2   ext4       rw,relatime,seclabel
From the displayed result, you can see mount information such as mount points, mounted devices, file system types, and mount attributes. Each entry is displayed in a directory structure, which is intuitive.
View mount information for a specific file system by specifying the file system type, as shown below:
findmnt -t ext4
Output example:
TARGET  SOURCE              FSTYPE OPTIONS
/       /dev/mapper/os-root ext4   rw,relatime,seclabel
├─/boot /dev/sda2           ext4   rw,relatime,seclabel
├─/home /dev/mapper/os-home ext4   rw,relatime,seclabel
└─/data /dev/sdb2           ext4   rw,relatime,seclabel
Display mount information under a specific mount point by specifying the mount point, as shown below:
findmnt /
Output example:
TARGET SOURCE              FSTYPE OPTIONS
/      /dev/mapper/os-root ext4   rw,relatime,seclabel

Uninstalling a File System

Using umount to Uninstall a File System

When a file system is no longer in use, you can unmount it by using the umount command, as shown below:
umount /home/test
For more detailed options, see man umount.

File System Occupancy Preventing Uninstallation

If a running process is occupying the mount point or its subdirectories, the file system cannot be unmounted, as shown below:
umount /home/test
Output example:
umount: /home/test: target is busy.
You can use fuser to check the occupancy of the directory, as shown below:
fuser -vm /home/test
Output example:
                     USER        PID ACCESS COMMAND
/home/test:          root     kernel mount /home/test
                     root       5360 ...e. main
If you determine that the process is no longer needed, you can add the -k option to kill the occupying process, as shown below:
fuser -kvm /home/test
Output example:
                     USER        PID ACCESS COMMAND
/home/test:          root     kernel mount /home/test
                     root       5360 ...e. main
[1]+  Killed                  /home/test/main
After killing the occupying process, use the umount command to unmount the file system.

Viewing File System

Using tune2fs to View ext4 File System Information

You can use tune2fs to view ext4 file system information, as shown in the following example:
tune2fs -l /dev/sdb2
Output example:
tune2fs 1.46.5 (30-Dec-2021)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          f9ce3b49-da65-4eca-8692-7daf78db5dae
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags:         unsigned_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              524288
Block count:              2097152
Reserved block count:     104857
Overhead clusters:        58505
Free blocks:              2038641
Free inodes:              524277
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Reserved GDT blocks:      1023
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Mon May 29 14:12:24 2023
Last mount time:          Mon May 29 19:23:26 2023
Last write time:          Mon May 29 19:23:26 2023
Mount count:              1
Maximum mount count:      -1
Last checked:             Mon May 29 14:12:24 2023
Check interval:           0 (<none>)
Lifetime writes:          4129 kB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     32
Desired extra isize:      32
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      1f267a9b-0e32-493e-b2bc-36dfff3493e6
Journal backup:           inode blocks
Checksum type:            crc32c
Checksum:                 0xbaacede8
From the displayed result, you can see the features enabled for the file system, Inode information, block information, group information, and so on.
For more detailed options, see man tune2fs.

Using dumpe2fs to View ext4 File System Information

You can use dumpe2fs to view ext4 file system group information, as shown in the following example:
# dumpe2fs /dev/sdb2
dumpe2fs 1.46.5 (30-Dec-2021)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          f9ce3b49-da65-4eca-8692-7daf78db5dae
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags:         unsigned_directory_hash 
Default mount options:    user_xattr acl
...
Journal start:            1
Journal checksum type:    crc32c
Journal checksum:         0xcc4acf7c

Group 0: (Blocks 0-32767) csum 0xc849 [ITABLE_ZEROED]
  Primary superblock at 0, Group descriptors at 1-1
  Reserved GDT blocks at 2-1024
  Block bitmap at 1025 (+1025), csum 0xa213e783
  Inode bitmap at 1041 (+1041), csum 0xad0eeccc
  Inode table at 1057-1568 (+1057)
  23513 free blocks, 8181 free inodes, 2 directories, 8181 unused inodes
  Free blocks: 9255-32767
  Free inodes: 12-8192
Group 1: (Blocks 32768-65535) csum 0x880b [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED]
  Backup superblock at 32768, Group descriptors at 32769-32769
  Reserved GDT blocks at 32770-33792
  Block bitmap at 1026 (bg #0 + 1026), csum 0x00000000
  Inode bitmap at 1042 (bg #0 + 1042), csum 0x00000000
  Inode table at 1569-2080 (bg #0 + 1569)
  31743 free blocks, 8192 free inodes, 0 directories, 8192 unused inodes
  Free blocks: 33793-65535
  Free inodes: 8193-16384
Group 2: (Blocks 65536-98303) csum 0x894a [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED]
  Block bitmap at 1027 (bg #0 + 1027), csum 0x00000000
  Inode bitmap at 1043 (bg #0 + 1043), csum 0x00000000
  Inode table at 2081-2592 (bg #0 + 2081)
  32768 free blocks, 8192 free inodes, 0 directories, 8192 unused inodes
  Free blocks: 65536-98303
  Free inodes: 16385-24576
Group 3: (Blocks 98304-131071) csum 0xc70e [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED]
  Backup superblock at 98304, Group descriptors at 98305-98305
  Reserved GDT blocks at 98306-99328
  Block bitmap at 1028 (bg #0 + 1028), csum 0x00000000
  Inode bitmap at 1044 (bg #0 + 1044), csum 0x00000000
  Inode table at 2593-3104 (bg #0 + 2593)
  31743 free blocks, 8192 free inodes, 0 directories, 8192 unused inodes
  Free blocks: 99329-131071
  Free inodes: 24577-32768
...
From the displayed result, you can see that the first half contains file system summary information, which is similar to the information viewed by tune2fs, and the second half contains metadata information for each group.

Using xfs_info to View xfs File System Information

You can use xfs_info to view xfs file system information, as shown in the following example:
xfs_info /dev/sdb3
Output example:
meta-data=/dev/sdb3              isize=512    agcount=4, agsize=4096 blks
         =                       sectsz=4096  attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=1    bigtime=0 inobtcount=0
data     =                       bsize=4096   blocks=16384, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=1221, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
From the displayed result, you can see the file system metadata area information, data area information, log area information, and so on.
For more detailed options, see man xfs_info.

Backing Up and Restoring File Systems

Using e2image to Back Up an ext4 File System

Before backup, unmount the file system. After the unmount is complete, run the following command:
e2image block-device ext4-metadata.img
block-device: the block device of the file system to be backed up.
ext4-metadata.img: the name of the backup file.
The above command does not add any parameters and only backs up metadata. The backup file format is normal, which is the only format supported by the restore feature of e2image.
Use the -r option to save in raw format, and use the -Q option to save in qcow2 format. To save data, add the -a option, as shown below:
e2image -r -a block-device ext4-backup.img
The raw format file saved by e2image is a sparse file and can be compressed to save space. The command is as follows:
e2image -r block-device - | bzip2 > ext4-backup.img.bz2
The raw format file backed up by e2image can be directly mounted using the mount command, as shown below:
mount ext4-backup.img mountpoint
After mounting, you can view files in the file system through the mount point. You can also view backup files by using commands such as tune2fs and dumpe2fs.
For more detailed options, see man e2image.

Using e2image to Restore ext4 File System Metadata

You can use the following command to restore ext4 file system metadata:
e2image -I block-device ext4-metadata.img
ext4-metadata.img is a metadata backup file in normal format saved by the e2image command.
Note:
e2image restores only metadata and cannot restore data.

Using dump to Back Up an ext4 File System

Before backup, unmount the file system. After the unmount is complete, run the following command:
dump -0uf backup-file block-device
The system partition information is as follows:
lsblk
Output example:
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda           8:0    0   64G  0 disk 
├─sda1        8:1    0   50M  0 part /boot/efi
├─sda2        8:2    0  512M  0 part /boot
└─sda3        8:3    0 63.4G  0 part 
  ├─os-root 253:0    0   30G  0 lvm  /
  └─os-home 253:1    0 33.4G  0 lvm  /home
The following example backs up /dev/sda2, which is the boot partition:
dump -0uf /home/sda2.backup /dev/sda2

Using restore to Restore an ext4 File System

If the file system on /dev/sda2 is corrupted, the following example demonstrates how to restore the system boot partition from the backup file of restore.
First, create an ext4 file system on /dev/sda2:
mkfs.ext4 /dev/sda2
Then mount /dev/sda2 to the /boot directory:
mount /dev/sda2 /boot
Go to the boot directory and run the following command:
restore -rf /home/sda2.backup
After the execution is complete, the files in the boot partition are restored.

Using xfs_copy to Back Up an xfs File System

Before backup, unmount the file system. After the unmount is complete, run the following command:
xfs_copy block-device xfs-backup.img
xfs_copy backs up metadata and actual data. The backup file can be mounted directly by using the mount command, or viewed by using the xfs_info command.

Using xfs_metadump to Back Up xfs File System Metadata

Before backup, unmount the file system. After the unmount is complete, run the following command:
xfs_metadump -a block-device xfs-metadata.img
xfs_metadump saves only file system metadata and can be used to restore an xfs file system.

Using xfs_mdrestore to Restore xfs File System Metadata

You can use the following command to restore xfs file system metadata:
xfs_mdrestore -gi xfs-metadata.img block-device
Note:
xfs_mdrestore restores only metadata and cannot restore data.

Using xfsdump to Back Up an xfs File System

Execute the following command:
xfsdump -l level -L session_label -M media_label -f backup-file path
level: backup level. 0 indicates a full backup.
session_label: session tag, used to identify backup information. It can be any string of less than 255 characters.
media_label: media tag, used to identify the backup medium. It can be any string of less than 255 characters.
backup-file: the generated backup file. path indicates the directory to be backed up.
The following example backs up the contents of the /data directory (the mount point of /dev/sdb6):
xfsdump -l 0 -L "backup_data" -M "backup_sdb6" -f /home/sdb6.backup /data

Using xfsrestore to Restore an xfs File System

If the file system on /dev/sdb6 is corrupted, the following example demonstrates how to restore it from the backup file of xfsrestore.
First, create an xfs file system on /dev/sdb6:
mkfs.xfs /dev/sdb6
Then mount /dev/sdb6 to the /data directory:
mount /dev/sdb6 /data
Execute the following command:
xfsrestore -f /home/sdb6.backup /data
After the execution is complete, the files in /data are restored.

Adjusting a File System

Using tune2fs to Adjust ext4 File System Attributes

You can use the -e option to adjust the behavior of the file system when an error is reported in the kernel. Use the following command to view the current behavior:
tune2fs -l /dev/sdb2 | grep "Errors behavior"
Errors behavior:          Continue
By default, TencentOS Server takes no action. The following example adjusts the behavior on error to remount the file system as read-only to protect the file system:
tune2fs -e remount-ro /dev/sdb2
You can use the -o option to adjust the current mount attributes of the file system. Add ^ before an attribute to disable it. Use the following command to view the current default mount attributes:
tune2fs -l /dev/sdb2 | grep "Default mount options"
Default mount options:    user_xattr acl
The following example disables the acl attribute and enables the debug attribute:
tune2fs -o ^acl,debug /dev/sdb2
You can use the -O option to adjust certain current features of the file system. Add ^ before a feature to disable it. Use the following command to view the current default features:
tune2fs -l /dev/sdb2 | grep "Filesystem features"
The following example disables the metadata_csum feature and enables the mmp feature:
tune2fs -O ^metadata_csum,mmp /dev/sdb2

Using resize2fs to Adjust ext4 File System Capacity

resize2fs supports online expansion (when the file system is mounted) and offline expansion and shrinkage (when the file system is unmounted). The command is as follows:
resize2fs block-device size
When size is smaller than the current capacity, shrinking is performed, which may cause data loss. When size is greater than the current capacity, expansion is performed. The resize2fs command cannot adjust the partition size itself, so size must be less than or equal to the sum of the current file system capacity and the remaining capacity of the partition where it resides. When the file system is mounted, only expansion is supported.

Typically, you can first expand the partition by using the growpart command, as shown below:
Use the growpart command to increase the partition size. If there is no available capacity between the partition to be expanded and the next partition (or after the last partition), the expansion cannot be performed. The expansion operation will occupy all available capacity between the partition and the next partition (or after the last partition).
The following example expands the 8th partition on the /dev/sdb disk. Before the expansion, the partition size is 1G and the file system size is 1G:
growpart /dev/sdb 8
After the expansion, the partition size is 46G. The following command uses resize2fs to adjust the file system size to 8G:
resize2fs /dev/sdb8 8G
Additionally, you can use lvextend/lvreduce to expand or shrink the file system on a logical volume.

Using xfs_admin to Adjust xfs File System Parameters

You can use the xfs_admin command to adjust XFS file system parameters. The following command enables the bigtime feature of the XFS file system:
xfs_admin -O bigtime=1 block-device
Note:
This feature supports upgrades but not downgrades, meaning that once enabled, it cannot be disabled.

Using xfs_growfs to Adjust xfs File System Capacity

xfs supports only online expansion (when the file system is mounted) and does not support shrinkage. The command is as follows:
xfs_growfs -d <mount point>
This command occupies all remaining available space. To specify a size, use the -D option:
xfs_growfs -D size <mount point>
size is the number of blocks after expansion. The xfs_growfs command cannot adjust the partition size itself, so the expanded capacity must be less than or equal to the current capacity plus the remaining capacity of the partition where it resides.

Fix the file system

Using fsck.ext4 to Repair an ext4 File System

You can use fsck, fsck.ext4, or e2fsck to check and repair file systems. fsck is the frontend entry point and ultimately calls fsck.ext4. You can specify the file system type with the -t option. If not specified, fsck automatically detects it. The binary file corresponding to fsck.ext4 is a hard link to /usr/sbin/e2fsck, and the two commands are identical.
Note:
Before performing a check or repair, unmount the file system.
The following example attempts to automatically repair file system errors. When manual intervention is required, the repair stops and exits:
fsck.ext4 -p /dev/sdb5
Output example:
/dev/sdb5: One or more block group descriptor checksums are invalid.  FIXED.
/dev/sdb5: Group descriptor 0 checksum is 0x0000, should be 0x471e.  FIXED.
/dev/sdb5: Group descriptor 1 checksum is 0x0000, should be 0x6325.  FIXED.
/dev/sdb5: Group descriptor 2 checksum is 0x0000, should be 0x0f68.  FIXED.
/dev/sdb5: Group descriptor 3 checksum is 0x0000, should be 0x2b53.  FIXED.
fsck.ext4: A block group is missing an inode table while reading bad blocks inode

/dev/sdb5: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
        (i.e., without -a or -p options)
With the -a option, the repair is completed automatically without any prompts. The -p option is recommended.
When automatic repair cannot completely fix file system errors, you can use the manual repair command. Manual repair requires manual confirmation.
The following example performs a manual repair, which requires manual confirmation:
fsck.ext4 /dev/sdb5
Output example:
e2fsck 1.46.5 (30-Dec-2021)
ext2fs_check_desc: Corrupt group descriptor: bad block for block bitmap
fsck.ext4: Group descriptors look bad... trying backup blocks...
/dev/sdb5 contains a file system with errors, check forced.
Resize inode not valid.  Recreate<y>?
You can add the -n option to reply no to all situations that require manual confirmation, thereby checking the file system:
fsck.ext4 -n /dev/sdb5
Output example:
e2fsck 1.46.5 (30-Dec-2021)
ext2fs_check_desc: Corrupt group descriptor: bad block for block bitmap
fsck.ext4: Group descriptors look bad... trying backup blocks...
/dev/sdb5 contains a file system with errors, check forced.
Resize inode not valid.  Recreate? no

Pass 1: Checking inodes, blocks, and sizes
Inode 7, i_blocks is 1520, should be 1504.  Fix? no

Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #0 (4294967295, counted=30644).
Fix? no

Free blocks count wrong for group #1 (0, counted=32703).
Fix? no
...

Free inodes count wrong for group #0 (0, counted=8181).
Fix? no

Directories count wrong for group #0 (0, counted=2).
Fix? no
...

Padding at end of inode bitmap is not set. Fix? no

Inode bitmap differences: Group 0 inode bitmap does not match checksum.
IGNORED.
Group 1 inode bitmap does not match checksum.
IGNORED.
Group 2 inode bitmap does not match checksum.
IGNORED.
...

/dev/sdb5: ********** WARNING: Filesystem still has errors **********

/dev/sdb5: 226/32768 files (0.0% non-contiguous), 67111/131072 blocks
You can add the -y option to reply yes to situations that require manual confirmation, thereby enabling automatic repair:
fsck.ext4 -y /dev/sdb5
Output example:
e2fsck 1.46.5 (30-Dec-2021)
ext2fs_check_desc: Corrupt group descriptor: bad block for block bitmap
fsck.ext4: Group descriptors look bad... trying backup blocks...
/dev/sdb5 contains a file system with errors, check forced.
Resize inode not valid.  Recreate? yes

Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #0 (4294967294, counted=30644).
Fix? yes

Free blocks count wrong for group #1 (0, counted=32703).
Fix? yes

Free blocks count wrong for group #2 (0, counted=32768).
Fix? yes

Free blocks count wrong for group #3 (0, counted=32703).
Fix? yes

Free blocks count wrong (63960, counted=128818).
Fix? yes

Free inodes count wrong for group #0 (0, counted=8181).
Fix? yes

Directories count wrong for group #0 (0, counted=2).
Fix? yes

Free inodes count wrong for group #1 (0, counted=8192).
Fix? yes

Free inodes count wrong for group #2 (0, counted=8192).
Fix? yes

Free inodes count wrong for group #3 (0, counted=8192).
Fix? yes

Free inodes count wrong (32542, counted=32757).
Fix? yes

Padding at end of inode bitmap is not set. Fix? yes

/dev/sdb5: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sdb5: 11/32768 files (0.0% non-contiguous), 2254/131072 blocks
Not all file system errors can be repaired by the fsck.ext4 command. You can determine the specific situation based on the return value of fsck.ext4:
0: No errors.
1: The file system errors have been repaired.
2: The file system errors have been repaired, and the system needs to be restarted.
4: The file system errors have not been repaired.
8: Operational error.
16: Usage or syntax error.
32: The user canceled the e2fsck operation.
128: Shared library error.

Using xfs_repair to Repair an xfs File System

You can use the -n option so that xfs_repair does not perform actual repairs but only checks the file system:
# xfs_repair -n /dev/sdb5
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
Metadata CRC error detected at 0xaaaab6b205a0, xfs_agi block 0x10/0x1000
agi has bad CRC for ag 0
bad magic # 0x0 for agi 0
bad version # 0 for agi 0
bad length # 0 for agi 0, should be 32768
bad uuid 00000000-0000-0000-0000-000000000000 for agi 0
would reset bad agi for ag 0
bad uncorrected agheader 0, skipping ag...
sb_icount 384, counted 320
sb_ifree 155, counted 123
sb_fdblocks 52465, counted 52139
root inode chunk not found
Phase 3 - for each AG...
        - scan (but don't clear) agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
imap claims in-use inode 131 is free, would correct imap
imap claims in-use inode 132 is free, would correct imap
...
imap claims in-use inode 159 is free, would correct imap
        - agno = 1
        - agno = 2
        - agno = 3
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - check for inodes claiming duplicate blocks...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
        - traversing filesystem ...
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify link counts...
No modify flag set, skipping filesystem flush and exiting.
The following example performs an actual repair:
# xfs_repair /dev/sdb5
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
Metadata CRC error detected at 0xaaaac43c05a0, xfs_agi block 0x10/0x1000
agi has bad CRC for ag 0
bad magic # 0x0 for agi 0
bad version # 0 for agi 0
bad length # 0 for agi 0, should be 32768
bad uuid 00000000-0000-0000-0000-000000000000 for agi 0
reset bad agi for ag 0
bad levels 0 for inobt root, agno 0
bad agbno 0 for inobt root, agno 0
bad levels 0 for finobt root, agno 0
bad agbno 0 for finobt root, agno 0
agi unlinked bucket 0 is 0 in ag 0 (inode=0)
agi unlinked bucket 1 is 0 in ag 0 (inode=0)
...
agi unlinked bucket 63 is 0 in ag 0 (inode=0)
sb_icount 384, counted 320
sb_ifree 155, counted 123
root inode chunk not found
Phase 3 - for each AG...
        - scan and clear agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
correcting imap
correcting imap
...
correcting imap
        - agno = 1
        - agno = 2
        - agno = 3
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - check for inodes claiming duplicate blocks...
        - agno = 0
        - agno = 2
        - agno = 3
        - agno = 1
Phase 5 - rebuild AG headers and trees...
        - reset superblock...
Phase 6 - check inode connectivity...
        - resetting contents of realtime bitmap and summary inodes
        - traversing filesystem ...
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
done

Previous Topic: LVM Logical Volume ManagementNext Topic: Using the GCC Compiler Toolchain

Help and Support

Was this page helpful?

Help us improve! Rate your documentation experience in 5 mins.

Feedback

Search
    Enter keywords to search documentation