Проверка диска на ошибки linux xfs

Команда xfs_repair восстанавливает поврежденные или поврежденные файловые системы XFS.

Она отличается высокой масштабируемостью, производительностью и предназначена для эффективного восстановления даже очень больших файловых систем с большим количеством inodes.

В отличие от других файловых систем Linux, xfs_repair не запускается во время загрузки, даже если файловая система XFS не была чисто размонтирована.

Это 64-битная журналируемая файловая система, которая поддерживает очень большие файлы (8 EB) и файловые системы (16 EB) на одном хосте.

XFS является файловой системой по умолчанию для Red Hat Enterprise Linux 7.

Восстанавливаемая файловая система не должна быть смонтирована перед выполнением xfs_repair, иначе результирующая файловая система может быть непоследовательной или поврежденной.

Эту же процедуру можно использовать для других системных разделов, которые нельзя размонтировать во время работы системы.

В этом руководстве мы покажем вам, как использовать команду ‘xfs_repair’ в Linux для восстановления поврежденной файловой системы XFS.

⛬ Файловая система XFS устанавливается только для чтения (CentOS / RHEL)

Общий синтаксис:

xfs_repair [option] [device or partition or mount point]

Содержание

  1. Повреждение файловой системы XFS
  2. 1) Восстановление файловой системы XFS
  3. Шаг-1: Размонтируйте файловую систему, для которой вы хотите запустить fsck.
  4. Шаг-2: Запустите xfs_repair с опцией ‘-n’, чтобы выполнить пробный запуск.
  5. Шаг-3: Запустите xfs_repair для восстановления файловой системы:
  6. Шаг-4: Как только файловая система будет восстановлена, смонтируйте раздел.
  7. 2) Восстановление тома XFS LVM с помощью xfs_repair
  8. Шаг-1: Убедитесь, что конкретный том LVM находится в активном состоянии для запуска xfs_repair. Чтобы проверить состояние LVM, выполните:
  9. Шаг-2: Размонтируйте устройство или файловую систему, для которой вы хотите запустить xfs_repair.
  10. Шаг-3: Запустите xfs_repair для восстановления файловой системы.
  11. Шаг-4: Как только файловая система будет восстановлена, смонтируйте раздел.
  12. Заключение

Повреждение файловой системы XFS

Мы намеренно испортим файловую систему XFS, выполнив следующую команду.

Она удалит случайно выбранные блоки метаданных файловой системы.

Примечание: Пожалуйста, не тестируйте это на производственном сервере, так как это может сильно повредить ваши данные.

Эта команда доступна только в отладочных версиях ‘xfs_db’.

Это полезно для тестирования xfs_repair и xfs_check.

sudo umount /data

Повреждение файловой системы xfs с помощью команды xfs_db.

sudo xfs_db -x -c blockget -c "blocktrash -s 512109 -n 1000" /dev/sdb1

blocktrash: 2/3 btino block 14 bits starting 2837:5 flipped
blocktrash: 3/5 btrefcnt block 411 bits starting 3714:0 flipped
blocktrash: 2/2 btcnt block 3 bits starting 2143:4 flipped
blocktrash: 2/2 btcnt block 1024 bits starting 523:4 flipped
blocktrash: 3/3 btino block 467 bits starting 1047:6 flipped
blocktrash: 3/4 btfino block 524 bits starting 1775:2 flipped
blocktrash: 0/5 btrefcnt block 224 bits starting 3086:6 flipped
.
.
blocktrash: 2/2 btcnt block 5 bits starting 3026:4 flipped
blocktrash: 2/5 btrefcnt block 1 bit starting 288:2 flipped
blocktrash: 0/4 btfino block 63 bits starting 1014:5 flipped
blocktrash: 0/17 inode block 24 bits starting 3533:1 flipped
blocktrash: 3/5 btrefcnt block 956 bits starting 2970:2 flipped
blocktrash: 2/3 btino block 482 bits starting 2368:3 flipped

Когда вы попытаетесь загрузить файловую систему, вы увидите следующее сообщение об ошибке, поскольку она была повреждена.

sudo mount -a

mount: /data: mount(2) system call failed: Structure needs cleaning.

1) Восстановление файловой системы XFS

Вы можете восстановить поврежденную файловую систему XFS без рута на работающей системе Linux.

Вам может понадобиться загрузить систему в режиме Rescue Mode или Emergency Mode для восстановления файловой системы, если ее невозможно размонтировать во время работы системы.

Шаг-1: Размонтируйте файловую систему, для которой вы хотите запустить fsck.

sudo umount /data

Шаг-2: Запустите xfs_repair с опцией ‘-n’, чтобы выполнить пробный запуск.

Обратите внимание, что инструмент ‘xfs_check’ был упразднен в пользу ‘xfs_repair -n’.

sudo xfs_repair -n /dev/sdb1

Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
Metadata CRC error detected at 0x564a76dad251, xfs_allocbt block 0x27fe08/0x1000
btree block 1/1 is suspect, error -74
Metadata CRC error detected at 0x564a76dad251, xfs_allocbt block 0x77fa08/0x1000
btree block 3/1 is suspect, error -74
invalid start block 4294967285 in record 0 of bno btree block 3/1
Metadata CRC error detected at 0x564a76dad251, xfs_allocbt block 0x4ffc08/0x1000
btree block 2/1 is suspect, error -74
.
.
free inode 190 contains errors, would correct
bad CRC for inode 191, would rewrite
UUID mismatch on inode 191
would have cleared inode 191
        - agno = 1
        - agno = 2
        - agno = 3
would rebuild corrupt refcount btrees.
No modify flag set, skipping phase 5
Inode allocation btrees are too corrupted, skipping phases 6 and 7
Maximum metadata LSN (2161919:-1) is ahead of log (1:20).
Would format log to cycle 2161922.
No modify flag set, skipping filesystem flush and exiting.

Шаг-3: Запустите xfs_repair для восстановления файловой системы:

sudo xfs_repair /dev/sdb1

Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
Metadata CRC error detected at 0x55ff18867251, xfs_allocbt block 0x4ffc08/0x1000
btree block 2/1 is suspect, error -74
Metadata CRC error detected at 0x55ff18867251, xfs_allocbt block 0x8/0x1000
btree block 0/1 is suspect, error -74
bad magic # 0xb1bdccbd in btbno block 0/1
Metadata CRC error detected at 0x55ff18867251, xfs_allocbt block 0x77fa08/0x1000
btree block 3/1 is suspect, error -74
.
.
clearing reflink flag on inode 133
Phase 5 - rebuild AG headers and trees...
        - reset superblock...
Phase 6 - check inode connectivity...
reinitializing root directory
reinitializing realtime bitmap inode
reinitializing realtime summary inode
        - resetting contents of realtime bitmap and summary inodes
        - traversing filesystem ...
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
disconnected inode 133, moving to lost+found
disconnected inode 137, moving to lost+found
disconnected inode 139, moving to lost+found
disconnected inode 140, moving to lost+found
Phase 7 - verify and correct link counts...
Maximum metadata LSN (2161919:-1) is ahead of log (1:20).
Format log to cycle 2161922.
done

Шаг-4: Как только файловая система будет восстановлена, смонтируйте раздел.

sudo mount /dev/sdb1

2) Восстановление тома XFS LVM с помощью xfs_repair

xfs_repair можно запускать на логических томах LVM так же, как файловые системы на стандартных разделах.

Для восстановления LVM-раздела следуйте приведенной ниже процедуре:

Шаг-1: Убедитесь, что конкретный том LVM находится в активном состоянии для запуска xfs_repair. Чтобы проверить состояние LVM, выполните:

sudo lvscan

  ACTIVE              '/dev/myvg/vol01' [1.00 GiB] inherit
  inactive            '/dev/myvg/vol02' [1.00 GiB] inherit
  ACTIVE              '/dev/rhel/swap' [2.07 GiB] inherit
  ACTIVE              '/dev/rhel/root' [<26.93 GiB] inherit

Если он “inactive“, активируйте его, выполнив следующую команду:

sudo lvchange -ay /dev/myvg/vol02 -v

  Activating logical volume myvg/vol02.
  activation/volume_list configuration setting not defined: Checking only host tags for myvg/vol02.
  Creating myvg-vol02
  Loading table for myvg-vol02 (253:3).
  Resuming myvg-vol02 (253:3).

Шаг-2: Размонтируйте устройство или файловую систему, для которой вы хотите запустить xfs_repair.

sudo umount /dev/myvg/vol02

Шаг-3: Запустите xfs_repair для восстановления файловой системы.

Для запуска xfs_repair необходимо ввести путь к LVM-тому, а не к реальному физическому разделу.

sudo xfs_repair /dev/myvg/vol02

Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
Metadata CRC error detected at 0x5581eed67251, xfs_allocbt block 0x180008/0x1000
btree block 3/1 is suspect, error -74
invalid start block 4294967285 in record 0 of bno btree block 3/1
Metadata CRC error detected at 0x5581eed67251, xfs_allocbt block 0x100008/0x1000
btree block 2/1 is suspect, error -74
.
.
junking entry "messages-20211004" in directory inode 128
bad attribute format 1 in inode 140, resetting value
        - agno = 1
        - agno = 2
        - agno = 3
clearing reflink flag on inode 133
Phase 5 - rebuild AG headers and trees...
        - reset superblock...
Phase 6 - check inode connectivity...
reinitializing root directory
reinitializing realtime bitmap inode
reinitializing realtime summary inode
        - resetting contents of realtime bitmap and summary inodes
        - traversing filesystem ...
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
disconnected inode 133, moving to lost+found
disconnected inode 137, moving to lost+found
disconnected inode 139, moving to lost+found
disconnected inode 140, moving to lost+found
disconnected inode 144, moving to lost+found
Phase 7 - verify and correct link counts...
Maximum metadata LSN (2161919:-1) is ahead of log (1:31).
Format log to cycle 2161922.
done

Шаг-4: Как только файловая система будет восстановлена, смонтируйте раздел.

sudo mount /apps1

Заключение

В этом руководстве мы показали вам, как восстановить поврежденную файловую систему XFS в Linux.

Также мы показали, как запустить xfs_repair на томах LVM.

Если у вас есть какие-либо вопросы или замечания, не стесняйтесь оставлять комментарии.

см. также:

🐧 Как проверить и восстановить файловую систему EXT4 на Linux

🐧 Как увеличить существующую файловую систему XFS на логический том LVM

🐧 Как вывести список служб, которые запускаются при загрузке на Linux

🐧 Советы по обеспечению безопасности сервера CentOS – часть 1

Источник

Red Hat Training

A Red Hat training course is available for RHEL 8

RHEL provides file system administration utilities which are capable of checking and repairing file systems. These tools are often referred to as fsck tools, where fsck is a shortened version of file system check. In most cases, these utilities are run automatically during system boot, if needed, but can also be manually invoked if required.

File system checkers guarantee only metadata consistency across the file system. They have no awareness of the actual data contained within the file system and are not data recovery tools.

22.1. Scenarios that require a file system check

The relevant fsck tools can be used to check your system if any of the following occurs:

  • System fails to boot
  • Files on a specific disk become corrupt
  • The file system shuts down or changes to read-only due to inconsistencies
  • A file on the file system is inaccessible

File system inconsistencies can occur for various reasons, including but not limited to hardware errors, storage administration errors, and software bugs.

File system check tools cannot repair hardware problems. A file system must be fully readable and writable if repair is to operate successfully. If a file system was corrupted due to a hardware error, the file system must first be moved to a good disk, for example with the dd(8) utility.

For journaling file systems, all that is normally required at boot time is to replay the journal if required and this is usually a very short operation.

However, if a file system inconsistency or corruption occurs, even for journaling file systems, then the file system checker must be used to repair the file system.

It is possible to disable file system check at boot by setting the sixth field in /etc/fstab to 0. However, Red Hat does not recommend doing so unless you are having issues with fsck at boot time, for example with extremely large or remote file systems.

Additional resources

  • fstab(5) man page.
  • fsck(8) man page.
  • dd(8) man page.

22.2. Potential side effects of running fsck

Generally, running the file system check and repair tool can be expected to automatically repair at least some of the inconsistencies it finds. In some cases, the following issues can arise:

  • Severely damaged inodes or directories may be discarded if they cannot be repaired.
  • Significant changes to the file system may occur.

To ensure that unexpected or undesirable changes are not permanently made, ensure you follow any precautionary steps outlined in the procedure.

22.3. Error-handling mechanisms in XFS

This section describes how XFS handles various kinds of errors in the file system.

Unclean unmounts

Journalling maintains a transactional record of metadata changes that happen on the file system.

In the event of a system crash, power failure, or other unclean unmount, XFS uses the journal (also called log) to recover the file system. The kernel performs journal recovery when mounting the XFS file system.

Corruption

In this context, corruption means errors on the file system caused by, for example:

  • Hardware faults
  • Bugs in storage firmware, device drivers, the software stack, or the file system itself
  • Problems that cause parts of the file system to be overwritten by something outside of the file system

When XFS detects corruption in the file system or the file-system metadata, it may shut down the file system and report the incident in the system log. Note that if the corruption occurred on the file system hosting the /var directory, these logs will not be available after a reboot.

Example 22.1. System log entry reporting an XFS corruption

# dmesg --notime | tail -15

XFS (loop0): Mounting V5 Filesystem
XFS (loop0): Metadata CRC error detected at xfs_agi_read_verify+0xcb/0xf0 [xfs], xfs_agi block 0x2
XFS (loop0): Unmount and run xfs_repair
XFS (loop0): First 128 bytes of corrupted metadata buffer:
00000000027b3b56: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000005f9abc7a: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000005b0aef35: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000000da9d2ded: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000001e265b07: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000006a40df69: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000000b272907: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000000e484aac5: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
XFS (loop0): metadata I/O error in "xfs_trans_read_buf_map" at daddr 0x2 len 1 error 74
XFS (loop0): xfs_imap_lookup: xfs_ialloc_read_agi() returned error -117, agno 0
XFS (loop0): Failed to read root inode 0x80, error 11

User-space utilities usually report the Input/output error message when trying to access a corrupted XFS file system. Mounting an XFS file system with a corrupted log results in a failed mount and the following error message: 

mount: /mount-point: mount(2) system call failed: Structure needs cleaning.

You must manually use the xfs_repair utility to repair the corruption.

Additional resources

  • xfs_repair(8) man page.

22.4. Checking an XFS file system with xfs_repair

This procedure performs a read-only check of an XFS file system using the xfs_repair utility. You must manually use the xfs_repair utility to repair any corruption. Unlike other file system repair utilities, xfs_repair does not run at boot time, even when an XFS file system was not cleanly unmounted. In the event of an unclean unmount, XFS simply replays the log at mount time, ensuring a consistent file system; xfs_repair cannot repair an XFS file system with a dirty log without remounting it first.

Although an fsck.xfs binary is present in the xfsprogs package, this is present only to satisfy initscripts that look for an fsck.file system binary at boot time. fsck.xfs immediately exits with an exit code of 0.

Procedure

  1. Replay the log by mounting and unmounting the file system: 

    # mount file-system
# umount file-system

    If the mount fails with a structure needs cleaning error, the log is corrupted and cannot be replayed. The dry run should discover and report more on-disk corruption as a result.

  2. Use the xfs_repair utility to perform a dry run to check the file system. Any errors are printed and an indication of the actions that would be taken, without modifying the file system. 

    # xfs_repair -n block-device

  3. Mount the file system: 

    # mount file-system

Additional resources

  • xfs_repair(8) man page.
  • xfs_metadump(8) man page.

22.5. Repairing an XFS file system with xfs_repair

This procedure repairs a corrupted XFS file system using the xfs_repair utility.

Procedure

  1. Create a metadata image prior to repair for diagnostic or testing purposes using the xfs_metadump utility. A pre-repair file system metadata image can be useful for support investigations if the corruption is due to a software bug. Patterns of corruption present in the pre-repair image can aid in root-cause analysis.

    • Use the xfs_metadump debugging tool to copy the metadata from an XFS file system to a file. The resulting metadump file can be compressed using standard compression utilities to reduce the file size if large metadump files need to be sent to support. 

      # xfs_metadump block-device metadump-file

  2. Replay the log by remounting the file system: 

    # mount file-system
# umount file-system

  3. Use the xfs_repair utility to repair the unmounted file system:

    • If the mount succeeded, no additional options are required: 

      # xfs_repair block-device

    • If the mount failed with the Structure needs cleaning error, the log is corrupted and cannot be replayed. Use the -L option (force log zeroing) to clear the log:

      This command causes all metadata updates in progress at the time of the crash to be lost, which might cause significant file system damage and data loss. This should be used only as a last resort if the log cannot be replayed. 

      # xfs_repair -L block-device

  4. Mount the file system: 

    # mount file-system

Additional resources

  • xfs_repair(8) man page.

22.6. Error handling mechanisms in ext2, ext3, and ext4

The ext2, ext3, and ext4 file systems use the e2fsck utility to perform file system checks and repairs. The file names fsck.ext2, fsck.ext3, and fsck.ext4 are hardlinks to the e2fsck utility. These binaries are run automatically at boot time and their behavior differs based on the file system being checked and the state of the file system.

A full file system check and repair is invoked for ext2, which is not a metadata journaling file system, and for ext4 file systems without a journal.

For ext3 and ext4 file systems with metadata journaling, the journal is replayed in userspace and the utility exits. This is the default action because journal replay ensures a consistent file system after a crash.

If these file systems encounter metadata inconsistencies while mounted, they record this fact in the file system superblock. If e2fsck finds that a file system is marked with such an error, e2fsck performs a full check after replaying the journal (if present).

Additional resources

  • fsck(8) man page.
  • e2fsck(8) man page.

22.7. Checking an ext2, ext3, or ext4 file system with e2fsck

This procedure checks an ext2, ext3, or ext4 file system using the e2fsck utility.

Procedure

  1. Replay the log by remounting the file system: 

    # mount file-system
# umount file-system

  2. Perform a dry run to check the file system. 

    # e2fsck -n block-device

    Any errors are printed and an indication of the actions that would be taken, without modifying the file system. Later phases of consistency checking may print extra errors as it discovers inconsistencies which would have been fixed in early phases if it were running in repair mode.

Additional resources

  • e2image(8) man page.
  • e2fsck(8) man page.

22.8. Repairing an ext2, ext3, or ext4 file system with e2fsck

This procedure repairs a corrupted ext2, ext3, or ext4 file system using the e2fsck utility.

Procedure

  1. Save a file system image for support investigations. A pre-repair file system metadata image can be useful for support investigations if the corruption is due to a software bug. Patterns of corruption present in the pre-repair image can aid in root-cause analysis.

    Severely damaged file systems may cause problems with metadata image creation.

    • If you are creating the image for testing purposes, use the -r option to create a sparse file of the same size as the file system itself. e2fsck can then operate directly on the resulting file. 

      # e2image -r block-device image-file

    • If you are creating the image to be archived or provided for diagnostic, use the -Q option, which creates a more compact file format suitable for transfer. 

      # e2image -Q block-device image-file

  2. Replay the log by remounting the file system: 

    # mount file-system
# umount file-system

  3. Automatically repair the file system. If user intervention is required, e2fsck indicates the unfixed problem in its output and reflects this status in the exit code. 

    # e2fsck -p block-device

    Additional resources

    • e2image(8) man page.
    • e2fsck(8) man page.
Источник

how-to-scan-and-repair-linux-disk-errors

In this article, you will learn how to repair Linux disk errors by using fsck and xfs_repair commands.

Table of Contents:

  • What is FSCK?
  • List Linux Disk Partitions and Types
  • Get Last Scanned Time of a Linux Disk
  • Scan & Repair a Ext4 Type Disk Partition
  • Enable Scanning of Ext4 Disk Partitions at Linux Startup
  • What is XFS_REPAIR?
  • Scan & Repair a XFS Type Disk Partition
  • Enable Scanning of XFS Disk Partitions at Linux Startup
  • Conclusion

What is FSCK?:

The system utility fsck (file system consistency check) is a tool for checking the consistency of a file system in Unix and Unix-like operating systems, such as Linux, macOS, and FreeBSD.

Generally, fsck is run either automatically at boot time, or manually by the system administrator. The command works directly on data structures stored on disk, which are internal and specific to the particular file system in use — so an fsck command tailored to the file system is generally required. The exact behaviors of various fsck implementations vary, but they typically follow a common order of internal operations and provide a common command-line interface to the user. (Source: Wikipedia)

how-to-scan-and-repair-linux-disk-errors

List Linux Disk Partitions and Types:

First of all you need to identify the disk partitions in your Linux server, their respective file systems and the path where they are being mounted.

If you are not used to Linux commandline then we recommend that you should attend online training Linux Command Line: From novice to wizard

By using a console or a ssh client, connect with your Linux server as root user.

You can execute the lsblk command with following switches at the Linux bash prompt to list the required information.

# lsblk -o NAME,FSTYPE,MOUNTPOINT
NAME        FSTYPE      MOUNTPOINT
sda
├─sda1      ext4        /boot
└─sda2      LVM2_member
  ├─cl-root xfs         /
  ├─cl-swap swap        [SWAP]
  └─cl-home xfs         /home
sr0

Get Last Scanned Time of a Linux Disk:

You can find the last scan time for Linux Ext4 type partitions with the help of following command.

# tune2fs -l /dev/sda1 | grep checked
Last checked:             Sun Sep 29 20:03:14 2019

Scan & Repair a Ext4 Type Disk Partition:

To scan a Linux disk partition, you can use fsck (File System Consistency Check) command. But you are required to unmount that partition before checking and repairing it.

# umount /dev/sda1

After successful unmount, execute fsck command at Linux bash prompt.

# fsck.ext4 /dev/sda1
e2fsck 1.45.6 (20-Mar-2020)
/dev/sda1: clean, 320/65536 files, 61787/262144 blocks

After checking and repairing your Linux disk, mount the partition again at its respective mountpoint.

For this purpose, execute following Linux command to mount all the disk partitions listed in /etc/fstab file.

# mount -a

Enable Scanning of Ext4 Disk Partitions at Linux Startup:

To enable disk checking at the time of Linux startup. You have to modify the Mount Count parameter for that disk partition.

# tune2fs -c 1 /dev/sda1
tune2fs 1.45.6 (20-Mar-2020)
Setting maximal mount count to 1

Reboot your Linux server now.

# reboot

Linux command fsck is now check your Ext4 disk partition on startup.

After reboot, get the Last Checked value for your disk partition, now it will show you the time of last Linux startup.

# tune2fs -l /dev/sda1 | grep checked
Last checked:             Sun Aug  1 22:50:46 2021

Set back the Mount Count parameter, or it will keep performing disk scans on each Linux boot.

# tune2fs -c -1 /dev/sda1
tune2fs 1.45.6 (20-Mar-2020)
Setting maximal mount count to -1

What is XFS_REPAIR?:

XFS is a high-performance 64-bit journaling file system created by Silicon Graphics, Inc (SGI) in 1993. It was the default file system in SGI’s IRIX operating system starting with its version 5.3. XFS was ported to the Linux kernel in 2001; as of June 2014, XFS is supported by most Linux distributions, some of which use it as the default file system.

The xfs_repair utility is highly scalable and is designed to repair even very large file systems with many inodes efficiently. Unlike other Linux file systems, xfs_repair does not run at boot time, even when an XFS file system was not cleanly unmounted. In the event of an unclean unmount, xfs_repair simply replays the log at mount time, ensuring a consistent file system.

Scan & Repair a XFS Type Disk Partition:

XFS type disk partitions have their own set of commands, that are a little bit different from Ext4.

You must unmount a XFS disk partition before checking it for consistency.

# umount /dev/mapper/cl-home

We have xfs_repair command for checking and repairing the disk errors.

In some Linux distros, you may also find xfs_check command. This command only perform scanning of XFS type disk partitions and do not perform any repair.

But xfs_check command is not available in all Linux distros.

Alternatively, you can use xfs_repair command with -n switch to get the same functionality as of xfs_check.

# xfs_repair -n /dev/mapper/cl-home
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
        - found root inode chunk
Phase 3 - for each AG...
        - scan (but don't clear) agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
        - 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 above command only perform disk checking and do not try to repair any error.

Now, execute the xfs_repair command without -n switch and it will perform scanning and repairing of Linux disk partitions.

# xfs_repair /dev/mapper/cl-home
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
        - found root inode chunk
Phase 3 - for each AG...
        - scan and clear agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
        - 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
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

Remount the XFS partition at its original mountpoint as listed in /etc/fstab file.

# mount -a

Enable Scanning of XFS Disk Partitions at Linux Startup:

In some scenarios you cannot unmount a disk partition, if the disk is in use by the Linux operating system. For this reason you may have to defer the disk checking until next system boot.

To enable xfs_repair command to run on Linux startup, add «fsck.mode=force fsck.repair=yes» at the end of GRUB menu kernel command.

You can refer to our previous post about Editing GRUB menu.

After Linux startup, check the system log to verify the execution of disk repair command.

# journalctl | grep  systemd-fsck

To permanently enable disk checking at startup, you have to add «fsck.mode=force fsck.repair=yes» in GRUB configuration files.

Edit grub configuration file in vim text editor.

# vi /etc/default/grub

Locate GRUB_CMDLINE_LINUX parameter and append «fsck.mode=force fsck.repair=yes» at the end of line.

GRUB_CMDLINE_LINUX="resume=/dev/mapper/cl-swap rd.lvm.lv=cl/root rd.lvm.lv=cl/swap rhgb quiet fsck.mode=force fsck.repair=yes"

Regenerate GRUB menu configurations based on new parameters.

# grub2-mkconfig

Reboot your Linux operating system to verify the new settings.

# reboot

Conclusion:

You have successfully performed scanning and repairing of Linux Disk partitions of Ext4 and XFS types. If you feel any difficulty understanding this Linux tutorial, we suggest that you should read The Linux Command Line, 2nd Edition by William Shotts.

Источник
fsck.xfs(8) System Manager’s Manual fsck.xfs(8)

NAME

fsck.xfs — do nothing, successfully

SYNOPSIS

fsck.xfs [ filesys … ]

DESCRIPTION

fsck.xfs is called by the generic Linux fsck(8)
program at startup to check and repair an XFS filesystem. XFS is a
journaling filesystem and performs recovery at mount(8) time if
necessary, so fsck.xfs simply exits with a zero exit status.

If you wish to check the consistency of an XFS filesystem, or
repair a damaged or corrupt XFS filesystem, see xfs_repair(8).

However, the system administrator can force fsck.xfs to run
xfs_repair(8) at boot time by creating a /forcefsck file or booting
the system with «fsck.mode=force» on the kernel command line.

FILES

/etc/fstab.

SEE ALSO

fsck(8), fstab(5), xfs(5),
xfs_repair(8).

Источник

xfs_repair command repairs corrupt or damaged XFS filesystems.

It’s highly scalable, high-performance and is designed to effectively repair even very large file systems with many inodes. Unlike other Linux file systems, xfs_repair does not run at boot time, even if the XFS file system was not cleanly unmounted.

It’s 64-bit journaling file system that supports very large files (8 EB) and file systems (16 EB) on a single host. XFS is the default file system for Red Hat Enterprise Linux 7.

The file system to be repaired must not be mounted before performing xfs_repair, otherwise the resulting file system may be inconsistent or corrupt.

This same procedure can be used for other system partitions that can’t be unmounted while the system is running.

In this guide, we’ll show you how to use the ‘xfs_repair’ command in Linux to repair a corrupted XFS file system.

Common Syntax:

xfs_repair [option] [device or partition or mount point]

Corrupting XFS File System

We are going to intentionally corrupt the XFS file system by executing the below command. It trash’s randomly selected file system metadata blocks.

Make a Note: Please don’t test this on Production server, as this may damage your data badly.

Trash occurs for randomly selected bits in selected blocks. This command is only available in debug versions of ‘xfs_db’. This is useful for testing xfs_repair and xfs_check.

sudo umount /data

Corrupting the xfs file system using the xfs_db command.

sudo xfs_db -x -c blockget -c "blocktrash -s 512109 -n 1000" /dev/sdb1

blocktrash: 2/3 btino block 14 bits starting 2837:5 flipped
blocktrash: 3/5 btrefcnt block 411 bits starting 3714:0 flipped
blocktrash: 2/2 btcnt block 3 bits starting 2143:4 flipped
blocktrash: 2/2 btcnt block 1024 bits starting 523:4 flipped
blocktrash: 3/3 btino block 467 bits starting 1047:6 flipped
blocktrash: 3/4 btfino block 524 bits starting 1775:2 flipped
blocktrash: 0/5 btrefcnt block 224 bits starting 3086:6 flipped
.
.
blocktrash: 2/2 btcnt block 5 bits starting 3026:4 flipped
blocktrash: 2/5 btrefcnt block 1 bit starting 288:2 flipped
blocktrash: 0/4 btfino block 63 bits starting 1014:5 flipped
blocktrash: 0/17 inode block 24 bits starting 3533:1 flipped
blocktrash: 3/5 btrefcnt block 956 bits starting 2970:2 flipped
blocktrash: 2/3 btino block 482 bits starting 2368:3 flipped

When you try to load the file system, you will see the following error message because it was corrupted.

sudo mount -a

mount: /data: mount(2) system call failed: Structure needs cleaning.

1) Repairing an XFS File System

You can repair a non-root corrupted XFS file system on a running Linux system. You may need to boot the system with Rescue Mode or Emergency Mode to repair the file system when it can’t be unmounted while the system is running.

Step-1: Unmount the filesystem that you want to run fsck.

sudo umount /data

Step-2: Run xfs_repair with '-n' option to perform a dry run. Please note that the ‘xfs_check’ tool has been deprecated in favor of ‘xfs_repair -n’.

sudo xfs_repair -n /dev/sdb1

Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
Metadata CRC error detected at 0x564a76dad251, xfs_allocbt block 0x27fe08/0x1000
btree block 1/1 is suspect, error -74
Metadata CRC error detected at 0x564a76dad251, xfs_allocbt block 0x77fa08/0x1000
btree block 3/1 is suspect, error -74
invalid start block 4294967285 in record 0 of bno btree block 3/1
Metadata CRC error detected at 0x564a76dad251, xfs_allocbt block 0x4ffc08/0x1000
btree block 2/1 is suspect, error -74
.
.
free inode 190 contains errors, would correct
bad CRC for inode 191, would rewrite
UUID mismatch on inode 191
would have cleared inode 191
        - agno = 1
        - agno = 2
        - agno = 3
would rebuild corrupt refcount btrees.
No modify flag set, skipping phase 5
Inode allocation btrees are too corrupted, skipping phases 6 and 7
Maximum metadata LSN (2161919:-1) is ahead of log (1:20).
Would format log to cycle 2161922.
No modify flag set, skipping filesystem flush and exiting.

Step-3: Run xfs_repair to repair the file system:

sudo xfs_repair /dev/sdb1

Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
Metadata CRC error detected at 0x55ff18867251, xfs_allocbt block 0x4ffc08/0x1000
btree block 2/1 is suspect, error -74
Metadata CRC error detected at 0x55ff18867251, xfs_allocbt block 0x8/0x1000
btree block 0/1 is suspect, error -74
bad magic # 0xb1bdccbd in btbno block 0/1
Metadata CRC error detected at 0x55ff18867251, xfs_allocbt block 0x77fa08/0x1000
btree block 3/1 is suspect, error -74
.
.
clearing reflink flag on inode 133
Phase 5 - rebuild AG headers and trees...
        - reset superblock...
Phase 6 - check inode connectivity...
reinitializing root directory
reinitializing realtime bitmap inode
reinitializing realtime summary inode
        - resetting contents of realtime bitmap and summary inodes
        - traversing filesystem ...
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
disconnected inode 133, moving to lost+found
disconnected inode 137, moving to lost+found
disconnected inode 139, moving to lost+found
disconnected inode 140, moving to lost+found
Phase 7 - verify and correct link counts...
Maximum metadata LSN (2161919:-1) is ahead of log (1:20).
Format log to cycle 2161922.
done

Step-4: Once the file system is repaired, mount the partition.

sudo mount /dev/sdb1

2) Repairing XFS LVM Volume with xfs_repair

xfs_repair can be run on LVM logical volumes just like filesystems on standard partitions. Follow the below procedure for repairing a LVM partition:

Step-1: Make sure the specific LVM volume is in active state to run xfs_repair. To check the status of LVM, run:

sudo lvscan

  ACTIVE              '/dev/myvg/vol01' [1.00 GiB] inherit
  inactive            '/dev/myvg/vol02' [1.00 GiB] inherit
  ACTIVE              '/dev/rhel/swap' [2.07 GiB] inherit
  ACTIVE              '/dev/rhel/root' [<26.93 GiB] inherit

If it’s 'inactive', activate it by running the following command.

sudo lvchange -ay /dev/myvg/vol02 -v

  Activating logical volume myvg/vol02.
  activation/volume_list configuration setting not defined: Checking only host tags for myvg/vol02.
  Creating myvg-vol02
  Loading table for myvg-vol02 (253:3).
  Resuming myvg-vol02 (253:3).

Step-2: Unmount the device or filesystem that you want to run xfs_repair.

sudo umount /dev/myvg/vol02

Step-3: Run xfs_repair to repair the file system. You must enter the path of the LVM volume to run xfs_repair and not an actual physical partition.

sudo xfs_repair /dev/myvg/vol02

Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
Metadata CRC error detected at 0x5581eed67251, xfs_allocbt block 0x180008/0x1000
btree block 3/1 is suspect, error -74
invalid start block 4294967285 in record 0 of bno btree block 3/1
Metadata CRC error detected at 0x5581eed67251, xfs_allocbt block 0x100008/0x1000
btree block 2/1 is suspect, error -74
.
.
junking entry "messages-20211004" in directory inode 128
bad attribute format 1 in inode 140, resetting value
        - agno = 1
        - agno = 2
        - agno = 3
clearing reflink flag on inode 133
Phase 5 - rebuild AG headers and trees...
        - reset superblock...
Phase 6 - check inode connectivity...
reinitializing root directory
reinitializing realtime bitmap inode
reinitializing realtime summary inode
        - resetting contents of realtime bitmap and summary inodes
        - traversing filesystem ...
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
disconnected inode 133, moving to lost+found
disconnected inode 137, moving to lost+found
disconnected inode 139, moving to lost+found
disconnected inode 140, moving to lost+found
disconnected inode 144, moving to lost+found
Phase 7 - verify and correct link counts...
Maximum metadata LSN (2161919:-1) is ahead of log (1:31).
Format log to cycle 2161922.
done

Step-4: Once the file system is repaired, mount the partition.

sudo mount /data

Conclusion

In this tutorial, we’ve shown you how to repair a corrupted XFS filesystems on Linux. Also, shown you how to run xfs_repair on the LVM volumes.

If you have any questions or feedback, feel free to comment below.

Источник

Понравилась статья? Поделить с друзьями:
  • Проверка диска на ошибки hddscan
  • Проверка диска на ошибки chkdsk через командную строку
  • Проверка диска на ошибки chkdsk программа
  • Проверка и исправление ошибок оперативной памяти
  • Проверка диска на ошибки chkdsk win 10