kk Blog —— 通用基础

resuce 模式中mount fail

2021-07-21 13:55:00

https://www.dell.com/support/kbdoc/zh-cn/000181978/appsync-service-plan-failed-in-mount-copy-phase

症状

Error in Host OS message log file:

kernel: XFS (dm-32): Superblock has unknown read-only compatible features (0x4) enabled.
kernel: XFS (dm-32): Attempted to mount read-only compatible filesystem read-write.
kernel: XFS (dm-32): Filesystem can only be safely mounted read only.
kernel: XFS (dm-32): SB validate failed with error -22.

From Host OS dmesg log file:

[ 8.529818] XFS (dm-7): Mounting V5 Filesystem
[ 8.530257] XFS (dm-8): Mounting V5 Filesystem
[ 8.557572] XFS (dm-7): Ending clean mount
[ 9.253626] XFS (dm-8): Ending clean mount

Events logs:

Mount copy MILE_000002,<AppSync Host>,Error occurred during the execution of service plan <Service Plan name>
Mount copy HST_000065,<AppSync Host>,Failed to discover fc and iscsi adapter information on host <Mount Host>
Mount copy UNIX_000009,<Mount Host>,Rescan command failed on the host.

Mount Host logs:

acputil.py[647]:execute() Info:Running command: mount -t xfs -o nouuid,rw,relatime,attr2,inode64,noquota <FS>

host.py[4121]:mount() Error caught during mount: : ['mount: wrong fs type, bad option, bad superblock on <FS>,', ' missing codepage or helper program, or other error', '', ' In some cases useful info is found in syslog - try', ' dmesg | tail or so.'] 

原因

RHEL bug triggered by unsupported configuration of not matching the source and mount hosts OS version.

解决方案

In this case, user was on Higher Source Host version (RHEL 8) and in lower Mount host version (RHEL 7.9). User made a new mount host matching to Source host and Service Plan ran fine.

其他信息

After doing some google search, it seem to be an issue with XFS v5 filesystem. Some of the important points are:

a) XFS filesystem is using XFS v5 (as per the dmesg logs) and contains features not supported by the RHEL7 kernel.

b) As per RHEL https://access.redhat.com/solutions/4582401, we need to create the filesystem without the reflink feature to use a XFS filesystem in both RHEL 7 and RHEL 8. Customer is on RHEL 7.9. mkfs.xfs -m reflink=0 /dev/sdN

To avoid the error, “-m reflink=0” is needed which disables the incompatible copy-on-right reflink support.

Source:- https://www.humblec.com/ceph-csi-xfs-superblock-has-unknown-read-only-or-wrong-fs-type-bad-on-dev-rbd4-missing-codepage-or/

c) mkfs.xfs (starting with version 3.2.4 of xfsprogs) recently defaulted to version 5 superblock, with lots of new enhancements like metadata CRC checksums. Version 5 superblock requires a 3.16 kernel or better. This error is typical, you’re trying to mount the volume on a kernel which doesn’t support v5 superblocks, i. e. with a version prior to 3.16.

Be careful, when using recent versions of xfsprogs with older kernels. You’ll have to use these options to create a v4 filesystem: mkfs.xfs -m crc=0,finobt=0 /your/device

xfs文件系统修复 xfs_repair

2021-07-20 16:53:00

https://blog.csdn.net/theoldsod2000/article/details/105988902/

因为断电等原因可能无法开机，提示

Failed to start Remount Root and Kenal File System

可以通过xfs_repair命令进行修复。

[root@localhost ~]# xfs_repair
Usage: xfs_repair [options] device

Options:
  -f           The device is a file
  -L           Force log zeroing. Do this as a last resort.
  -l logdev    Specifies the device where the external log resides.
  -m maxmem    Maximum amount of memory to be used in megabytes.
  -n           No modify mode, just checks the filesystem for damage.
  -P           Disables prefetching.
  -r rtdev     Specifies the device where the realtime section resides.
  -v           Verbose output.
  -c subopts   Change filesystem parameters - use xfs_admin.
  -o subopts   Override default behaviour, refer to man page.
  -t interval  Reporting interval in seconds.
  -d           Repair dangerously.
  -V           Reports version and exits.

xfs_repair最重要的是指定要修复的设备

如果是LVM管理分区的

可以通过 ls -l /dev/mapper 来查看可用的设备。

一般可以看到2到3个链接文件，centos-home -> ../dm-1, centos-root->../dm-0

执行xfs_repair /dev/dm-0 正常情况下，这个分区就修复好了，再接着执行 xfs_repair /dev/dm-1，正常情况下，这个分区也会修复好。

如果不是LVM分区管理的，可以通过 ls /dev 查看，一般会有sda,sda1,sda2.

可以执行 xfs_repair /dev/sda1 和 xfs_repair /dev/sda2 进行修复。

如果修复失败，可以加上 -L 参数，这样可能会丢失部分数据。

修复的过程中可能会出错，提示找不到superblock。

下面这篇文章很清楚的讲述了superblock，inode，block的关系，可以帮助我们理解

https://blog.csdn.net/Ohmyberry/article/details/80427492

dm是device mapper的意思,主要涉及的linux下卷的管理。卷管理通过映射的方法建立了逻辑卷。每个逻辑卷相当于一个分区。

Linux下挂载lvm 重名问题

2021-07-20 16:47:00

https://blog.51cto.com/songxj/269661

linux下使用新硬盘安装系统，安装好以后再挂载原来的硬盘，分区格式全为系统默认分区，系统默认使用的是lvm格式，并且默认的卷都是 VolGroup00

使用 pvs 查看显示如下：

[root@localhost ~]# pvs
PV VG Fmt Attr PSize PFree
/dev/sda2 VolGroup00 lvm2 a- 136.62G 0
/dev/sdb2 VolGroup00 lvm2 a- 136.62G 0

发现可以正确认别到两个VG，但是同名，如何挂载呢？

解决办法是，将原来的VG更名，解决冲突即可挂载。

重命名格式为：

vgrename VolGroup00 VolGroup01

此时会提示：

[root@localhost ~]# vgrename VolGroup00 VolGroup01
Found more than one VG called VolGroup00. Please supply VG uuid.

原因是存在两个 VolGroup00，修改的方法他已经提示了要指定 VG uuid即可。

查看VG uuid的命令为：

[root@localhost ~]# vgs -v
Finding all volume groups
Finding volume group "VolGroup00"
Finding volume group "VolGroup00"
VG Attr Ext #PV #LV #SN VSize VFree VG UUID
VolGroup00 wz--n- 32.00M 1 2 0 136.62G 0 dcHa6G-abU2-Xfq8-EPBm-jBLj-sf18-O5uH0U
VolGroup00 wz--n- 32.00M 1 2 0 136.62G 0 OF8g7h-PQJB-9D9z-yPxn-1kfY-Advq-YbNHJ9

查到VG uuid以后，再次执行改名：

[root@localhost ~]# vgrename OF8g7h-PQJB-9D9z-yPxn-1kfY-Advq-YbNHJ9 VolGroup01
Volume group "VolGroup00" still has active LVs

修改成功以后，再执行：lvscan

[root@localhost ~]# lvscan
inactive '/dev/VolGroup01/LogVol00' [130.84 GB] inherit
inactive '/dev/VolGroup01/LogVol01' [5.78 GB] inherit
ACTIVE '/dev/VolGroup00/LogVol00' [130.84 GB] inherit
ACTIVE '/dev/VolGroup00/LogVol01' [5.78 GB] inherit

可以看到新修改的VolGroup01是inactive状态。

再使用vgchange 加载 VolGroup01

[root@localhost ~]# vgchange -ay /dev/VolGroup01
2 logical volume(s) in volume group "VolGroup01" now active

最后 mount 就可以

[root@localhost ~]# mount /dev/VolGroup01/LogVol00 /mnt/old

至此，全部完成。

← Older Blog Archives Newer →