新しい会話を開始

未解決

この投稿は5年以上前のものです

Community Manager

 • 

3.1K メッセージ

1884

2017年9月6日 01:00

DCA V1/V2/V3:xfs repairを実行してI/Oエラー「System has corrupt files. Unable to remove corrupt files from the file system」を解決する方法(000335023)

バージョン:10

記事タイプ:不具合修正

対象読者:レベル30 = お客様

最終発行日:20161110日木曜日10:51:54GMT

概要:

/data#1つのノードでのI/Oエラーが報告されており、/data#内のすべてのインスタンスが停止しているか、DCAファイル システムに破損したファイルが含まれています。

問題:

ケース1

/data#1つのノードでのI/Oエラーが報告されており、/data#内のすべてのインスタンスが停止しています。

例:

[root@sdw6 data2]# ls

ls: reading directory .: Input/output error

[root@mdw ~]# su - gpadmin PA-Full:gpadmin@mdw[~] gpstate -e

....

20150919:16:47:18:021629 gpstate:mdw:gpadmin-[INFO]:-----------------------------------------------------

20150919:16:47:18:021629 gpstate:mdw:gpadmin-[INFO]:-Segment Mirroring Status Report 20150919:16:47:18:021629

gpstate:mdw:gpadmin-[INFO]:-----------------------------------------------------

20150919:16:47:18:021629 gpstate:mdw:gpadmin-[INFO]:-Segments with Primary and Mirror Roles Switched 20150919:16:47:18:021629 gpstate:mdw:gpadmin-[INFO]:- Current Primary Port Mirror Port

20150919:16:47:18:021629 gpstate:mdw:gpadmin-[INFO]:- sdw7-2 50003 sdw6-2 40003 20150919:16:47:18:021629 gpstate:mdw:gpadmin-[INFO]:- sdw7-2 50004 sdw6-2 40004

20150919:16:47:18:021629 gpstate:mdw:gpadmin-[INFO]:- sdw7-2 50005 sdw6-2 40005

20150919:16:47:18:021629 gpstate:mdw:gpadmin-[INFO]:-----------------------------------------------------

20150919:16:47:18:021629 gpstate:mdw:gpadmin-[INFO]:-Primaries in Change Tracking

20150919:16:47:18:021629 gpstate:mdw:gpadmin-[INFO]:- Current Primary Port Change tracking size Mirror Port

20150919:16:47:18:021629 gpstate:mdw:gpadmin-[INFO]:- sdw5-2 40003 728 MB sdw6-2 50003

20150919:16:47:18:021629 gpstate:mdw:gpadmin-[INFO]:- sdw5-2 40004 714 MB sdw6-2 50004

20150919:16:47:18:021629 gpstate:mdw:gpadmin-[INFO]:- sdw5-2 40005 712 MB sdw6-2 50005

20150919:16:47:18:021629 gpstate:mdw:gpadmin-[INFO]:- sdw7-2 50003 565 MB sdw6-2 40003

20150919:16:47:18:021629 gpstate:mdw:gpadmin-[INFO]:- sdw7-2 50004 564 MB sdw6-2 40004

20150919:16:47:18:021629 gpstate:mdw:gpadmin-[INFO]:- sdw7-2 50005 568 MB sdw6-2 40005

ケース2

DCAファイル システムに破損したファイルが含まれています。

例:

[root@dal00sle0002 data2]# cd /data1/landingzone/ready/DCL.dcl_subscriber.old/ [root@dal00sle0002 DCL.dcl_subscriber.old]# ll

total 0

?--------- ? ? ? ? ? 20160319_0156_05963_SL_CP_20160318.0849Z+4944426.ready

原因:           原因は、サーバのコントローラ上のライト キャッシュの問題から、メタデータ トランザクション内のエラーまでさまざまです。原因を診断するには徹底的なRCAが必要です。

解決方法:

ケース1

/data#1つのノードでのI/Oエラーが報告されており、/data#内のすべてのインスタンスが停止しています。

影響を受けているファイル システムに対してxfs_repairを実行すると、問題が解決されます。

xfs_repairを実行する前の事前チェック:

 

  1. /data#のみが影響を受けていることを確認する必要があります。同じノードの他のファイル システムをチェックできます。ディレクトリのパーティション名をメモします。

例(sdw6data2):

[root@sdw6 ~]# df -h

Filesystem Size Used Avail Use% Mounted on /dev/sda2 46G 14G 30G 32% /

/dev/sda1 996M 82M 863M 9% /boot tmpfs 24G 0 24G 0% /dev/shm /dev/sdb

     2.7T 1.3T 1.4T 49% /data1 /dev/sdd

     2.7T 1.3T 1.4T 49% /data2

paproddd03a:/data/col1/padcabackup/paproddca01/db_dumps

29T 8.1T 21T 29% /backup


[root@sdw6 data1]# ls gpcheckperf

mirror primary

[root@sdw6 data2]# ls

ls: reading directory .: Input/output error

  1. 影響を受けているファイルシステムでハードウェアの故障が発生していないことを確認します。

               a.ファイル システムに属する物理ディスクを確認します。

               b.異常なエラーがコントローラのログで発生していないことを確認する必要があります。

1.データ ディレクトリ/data##はディレクトリ番号)をアンマウントします。

[root@sdw6 ~]# umount/data2

注:エラー メッセージ「umount: /data#: device is busy」が表示される場合、このページの「注」セクションに進み、代わりにlazyアンマウントを利用してください。

1.マウントのパーティション/dev/sd#xfscheckを実行します。

[root@sdw6 ~]# xfs_check /dev/sdd

1.マウントでxfsrepairを実行します。

[root@sdw6 ~]# xfs_repair -L /dev/sdd

1.正しいディレクトリにマウントを再マウントします。

[root@sdw6 ~]# mount -a /data2

1.マスター サーバにsshでログインし、gpadminユーザーに切り替えます。

[root@sdw6 ~]# ssh mdw [root@mdw ~]# su - gpadmin

1.gprecoversegを実行します。

[root@mdw ~]# gprecoverseg -a



ケース2

続行する前に、作業するノードのマウントとファイル システムを確認します。

例:

[root@mdw ~]# df -h

Filesystem

Size

Used Avail Use%

Mounted on

/dev/sda2

31G

12G

18G

41%

/

tmpfs

32G

0

32G

0%

/dev/shm

/dev/sda1

1008M

107M

850M

12%

/boot

/dev/sdb1

99G

189M

94G

1%

/home

/dev/sde

918G

315M

918G

1%

/data

/dev/sdd1

32G

177M

30G

1%

/var/crash

 

上の表で、FS /dev/sdeで、マウントは/dataです。次に、

xfs_repair操作を実行して、破損したinodeデータを修正します。次のように行います。

  1. 影響を受けているノードから、該当するファイル システムに、マウントを保持するロガー プロセスがないことを確認します。

例:

[root@sdw6 data2]# ps -ef | grep -i data1

root 10809 16447 0 17:12 pts/1 00:00:00 grep -i data1

gpadmin 22111 1 0 15:12 ? 00:00:04 gpfdist -d /data1 -p 8901 -l /data1/log/gpfdist-201603.log


1.マウントを保持するプロセスがある場合、そのプロセスをkillする必要があります (ロガー プロセスがない場合は、ステップ3に進みます)。このインスタンスで、次を実行できます。

[root@sdw6 data2]# pkill

注:プロセスによっては、pkillが適していない可能性があるため、このコマンドで処理を進める前に、停止するプロセスを調査します。

1.プロセスがkillされた後、データ ディレクトリをアンマウントします(#は、ディレクトリ番号)。

[root@sdw6 ~]# umount/data2

1. マウントでxfscheckを実行します。

                    [root@sdw6 ~]# xfs_check /dev/sdd

1.マウントでxfsrepairを実行します。

[root@sdw6 ~]# xfs_repair -L /dev/sdd

1.正しいディレクトリにマウントを再マウントします。

[root@sdw6 ~]# mount -a /data2

1.マスター サーバにsshでログインし、gpadminユーザーに切り替えます。

[root@sdw6 ~]# ssh mdw [root@mdw ~]# su - gpadmin

1.gprecoversegを実行します。

[root@mdw ~]# gprecoverseg -a

1.gpstate -eを使用してgpadminとしてデータベース ステータスを確認します。[root@mdw ~]# gpstate -e

注:

前述の3(ケース1)が次のエラー メッセージで失敗する場合:- umount: /data#: device is busy

[root@sdw6 ~]# umount -l /data2

ファイル システム階層からファイル システムを接続解除し、ビジーでなくなるとすぐに、ファイル システムへの参照をすべてクリーンアップします。これにより、ファイル システムが正常にアンマウントされます。

xfs_repairの実行中、最後に次のエラー メッセージが表示される場合

xfs_repair: /dev/sdd contains a mounted filesystem

fatal error -- couldn't initialize XFS library

次の手順を実行します。

  1. a. /etc/fstabファイルを編集して/data#エントリーをコメント化します。編集前の元のfstab

[root@sdw6 ~]# cat /etc/fstab

...

LABEL=/data1 /data1 xfs noatime,inode64,allocsize=16m 0 0 LABEL=/data2 /data2 xfs noatime,inode64,allocsize=16m 0 0

編集後の新しいfstab(この例では/data2をコメント アウト)

[root@sdw6 ~]# cat /etc/fstab

...

LABEL=/data1 /data1 xfs noatime,inode64,allocsize=16m 0 0

#LABEL=/data2 /data2 xfs noatime,inode64,allocsize=16m 0 0

  1. サーバを再起動します。
  2. 'xfs_repair /dev/sd#'の実行が引き続き失敗する場合は、xfs_repair -L を使用する必要があります。

[root@sdw6 ~]# xfs_repair /dev/sdd

Phase 1 - find and verify superblock...

Phase 2 - using internal log - zero log...

ERRORThe filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair.

Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this.

[root@sdw6 ~]# xfs_repair -L /dev/sdd Phase 1 - find and verify superblock...

Phase 2 - using internal log - zero log...

ALERT: The filesystem has valuable metadata changes in a log which is being destroyed because the -L option was used.

-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

4461d940: Badness in key lookup (length)

bp=(bno 179821952, len 16384 bytes) key=(bno 179821952, len 8192 bytes)

-agno = 1

-agno = 2

46e21940: Badness in key lookup (length)

bp=(bno 539478608, len 16384 bytes) key=(bno 539478608, len 8192 bytes)

-agno = 3

-agno = 4

-agno = 5

-agno = 6

4be29940: Badness in key lookup (length)

...

disconnected inode 10737418540, moving to lost+found

Phase 7 - verify and correct link counts...

done

  1. a. /etc/fstabファイルを編集して、/data2エントリーのコメントを削除します。

[root@sdw6 ~]# cat /etc/fstab

...

LABEL=/data1 /data1 xfs noatime,inode64,allocsize=16m 0 0 LABEL=/data2 /data2 xfs noatime,inode64,allocsize=16m 0 0

  1. ran 'mount -a' to mount/data2 entry

[root@sdw6 ~]# mount -a /data2 [root@sdw6 ~]# df -h

Filesystem Size Used Avail Use% Mounted on /dev/sda2 46G 14G 30G 32% /

/dev/sda1 996M 82M 863M 9% /boot tmpfs 24G 0 24G 0% /dev/shm /dev/sdb 2.7T 1.3T 1.4T 49% /data1

paproddd03a:/data/col1/padcabackup/paproddca01/db_dumps 29T 8.1T 21T 29% /backup

/dev/sdd 2.7T 1.3T 1.4T 48% /data2

次のように実行してIOエラーを解決します。

[root@sdw6 data2]# ls

gpcheckperf lost+found mirror primary

再起動後、sdw6内のすべてのインスタンスが停止します。それらのインスタンスを起動するには、通常のリカバリを実行します。

[root@mdw ~]# gprecoverseg -a


注:このアクションによって、再起動するサーバのすべてのインスタンスが停止するため、サーバを再起動する前に、お客様から許可を取得してください。


この記事は、ECNEMCコミュニティ ネットワーク)上にHVCとしてプロモートされています。https://community.emc.com/docs/DOC-55556

プライマリ       Data Computing Appliance V3

製品:

製品:           Data Computing Appliance V1Data Computing Appliance V2Data Computing Appliance V3

レスポンスがありません。
イベントは見つかりませんでした!

Top