Проверить xfs на ошибки centos 7

Команда 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]

Повреждение файловой системы 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

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)

Recommended Book: Practical Guide to Linux Commands, Editors, and Shell Programming by Mark Sobell & Matthew Helmke

Recommended Training:1Z0-409 Oracle Linux Fundamentals Certified Practice Exam

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.

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.

Hello, friends. In this post, we will explain a trick that can save a lot of work and even an entire system. So, today you will learn How to Check and Repair XFS Filesystem in RHEL/RockyLinux/CentOS.

Before we start, we need to talk a little about XFS.

XFS is a high-performance 64-bit journaling file system. Its virtues such as maturity, and debugged code, make it a preferred candidate for use on GNU/Linux servers.

Some main advantages of XFS are:

• Thanks to journaling, easy and fast recovery from data loss is possible. This feature is vital in a production server.
• With XFS, there is the possibility to enlarge the partition while it is mounted and active.
• XFS can execute I/O (Input/Output) operations in parallel.

And so on. That is why many servers with RHEL, RockyLinux and derivatives use it.

However, it is possible that it can fail us, so that is the reason for today’s post.

How to Repair XFS Filesystem in RHEL/RockyLinux/CentOS

Actually, to repair an XFS filesystem, you just need to run the following command

xfs_repair [option] [device]

However, we have to have a corrupted XFS system, and this on a production system is fatal.

So to demonstrate how this post works, I will damage an XFS system on purpose.

Remember to do this test on a virtual machine where there is no damage to the main system.

Let’s suppose that our partition or device or system is mounted in /device first we must unmount it.

umount /device

And now damage the file system by running

xfs_db -x -c blockget -c "blocktrash -s 512109 -n 1000" [device]

For example,

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

And of course if you try to mount it you should get an error similar to this one

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

So, let’s fix it.

For that, the volume has to be unmounted.

And to repair it run the following command

xfs_repair [device]

For example,

xfs_repair /dev/sdb1 

At the end you will see an output screen similar to this one

So, the process has been extensive.Now just mount.

mount /dev/sdb1

Enjoy it.

Install Red Hat Enterprise Linux 8.0.0
Test this media & install Red Hat Enterprise Linux 8.0.0
Troubleshooting                                    <--- Select

Install Red Hat Enterprise Linux 7.0 in basic graphics mode
Rescue a Red Hat Enterprise Linux system          <--- Select
Run a memory test

Boot from local drive

Return to main menu

# mdadm --examine --scan

# mdadm --assemble --scan

# vgchange -ay

# lvs  <-- To list logical volumes

# vgs  <-- To list volume groups

# e2fsck -fv /dev/mapper/<vg>-<lv>

# e2fsck -fv /dev/mapper/rhel-root

# e2fsck -fv /dev/<sd device>

# e2fsck -fv /dev/sda1

# e2fsck -fv /dev/md0

# xfs_repair /dev/mapper/<vg>-<lv>
or
# xfs_repair /dev/<sd device>
or
# xfs_repair /dev/<md device>

Didn’t find what you were looking for? Perform a quick search across GoLinuxCloud

If you’re attempting to run xfs_repair, getting the error message that suggests mounting the filesystem to replay the log, and after mounting still receiving the same error message, you may need to perform a forced repair (using the -L flag with xfs_repair). This option should be a last resort.

For example, I’ll use a case where I had a corrupt root partition on my CentOS 7 install. When attempting to mount the partition, I continually received the below error message:

mount: mount /dev/mapper/centos-root on /mnt/centos-root failed: Structure needs cleaning

Unfortunately, forcing a repair would involve zeroing out (destroying) the log before attempting a repair. When using this method, there is a potential of ending up with more corrupt data than initially anticipated; however, we can use the appropriate xfs tools to see what kind of damage may be caused before making any permanent changes.

Using xfs_metadump and xfs_mdrestore, you can create a metadata image of the affected partition and perform the forced repair on the image rather than the partition itself. The benefits of this is the ability to see the damage that comes with a forced repair before performing it on the partition.

To do this, you’ll need a decent sized USB or external hard drive. Start by mounting the USB drive — my USB was located at /dev/sdb1, yours may be named differently.

mkdir -p /mnt/usb
mount /dev/sdb1 /mnt/usb

Once mounted, run xfs_metadump to create a copy of the partition metadata to the USB — again, your affected partition may be different. In this case, I had a corrupt root partition located at /dev/mapper/centos-root:

xfs_metadump /dev/mapper/centos-root /mnt/usb/centos-root.metadump

Next, you’ll want to restore the metadata in to an image so that we can perform a repair and measure the damage.

xfs_mdrestore /mnt/usb/centos-root.metadump /mnt/usb/centos-root.img

I found that in rescue mode xfs_mdrestore is not available, and instead you’ll need to be in rescue mode of a live CentOS CD.

Finally, we can perform the repair on the image:

xfs_repair -L /mnt/usb/centos-root.img

After the repair has completed and you’ve assessed the output and potential damage, you can determine as to whether you’d like to perform the repair against the partition.

To run the repair against the partition, simply run:

xfs_repair -L /dev/mapper/centos-root

Don’t forget to check the other partitions for corruption as well. After the repairs, reboot the system and you should be able to successfully boot.

Remember that the -L flag should be used as a last resort where there are no other possible options to repair.

I found that these online articles helped:

• https://web.archive.org/web/20140920034637/http://geekblood.com/2014/08/13/filesystem-corruption-xfs-and-rhelv7/
• https://web.archive.org/web/20160319163101/http://oss.sgi.com/archives/xfs/2015-01/msg00503.html
• http://dhoytt.com/blog/2015/07/26/xfs-filesystem-repair-gets-web-server-back/