ls -al에서 파일이 -??????????로 표시되고 rm -rf로도 삭제되지 않는 경우, 단순 권한 문제가 아니라 디렉터리 엔트리와 inode 정보 불일치 등 XFS 메타데이터 손상을 의심한다. · 문제 경로: · 조회 시:
ls -al에서 파일이 -??????????로 표시되고 rm -rf로도 삭제되지 않는 경우, 단순 권한 문제가 아니라 디렉터리 엔트리와 inode 정보 불일치 등 XFS 메타데이터 손상을 의심한다.
이 글의 노션 원문 ↗ls -al에서 파일이 -??????????로 표시되고 rm -rf로도 삭제되지 않는 경우, 단순 권한 문제가 아니라 디렉터리 엔트리와 inode 정보 불일치 등 XFS 메타데이터 손상을 의심한다.
문제 경로:
/data1/19c/arch/WSMAINDB_1_2_1235437312.arc조회 시:
-?????????? ? ? ? ? ? WSMAINDB_1_2_1235437312.arc삭제 시에도 디렉터리가 비워지지 않음:
rm -rf *
rm: cannot remove 'arch': Directory not empty아직 댓글이 없습니다. 이 글에서 얻은 생각이나 질문을 남겨보세요.
로그인하고 댓글 남기기 →Pacemaker 리소스 구성:
Resource Group: oracle_grp
fs_data -> /data1
fs_arch -> /arch
vip_oracle
ora_lsnr실제 문제 파일은 /data1/19c/arch 아래에 있었으므로 복구 대상은 /arch의 vg_arch-lv_arch가 아니라 /data1의 vg_data-lv_data이다.
확인 명령:
findmnt /data1
findmnt /data1/19c/arch대상 장치:
/data1 -> /dev/mapper/vg_data-lv_data아직 댓글이 없습니다. 이 글에서 얻은 생각이나 질문을 남겨보세요.
로그인하고 댓글 남기기 →fs_data, fs_arch는 Pacemaker Filesystem 리소스로 관리된다. 따라서 단순히 umount하면 Pacemaker monitor가 장애로 판단하여 다시 mount할 수 있다.
이 글의 노션 원문 ↗fs_data, fs_arch는 Pacemaker Filesystem 리소스로 관리된다. 따라서 단순히 umount하면 Pacemaker monitor가 장애로 판단하여 다시 mount할 수 있다.
예:
fs_arch 20s-interval monitor ... returned 'not running'따라서 파일시스템 복구 작업 전에는 Pacemaker 리소스를 먼저 disable해야 한다.
pcs resource disable fs_data --wait=60아직 댓글이 없습니다. 이 글에서 얻은 생각이나 질문을 남겨보세요.
로그인하고 댓글 남기기 →최초 fs_data disable 시 다음과 같이 timeout 발생:
Error: waiting timeout
Pending actions:
fs_data_stop_0 on oel19PA원인은 /data1/disk4k.img를 backing file로 사용한 4K loop device가 /data1을 점유하고 있었기 때문이었다.
확인:
losetup -j /data1/disk4k.img결과:
/dev/loop0: (...) (/data1/disk4k.img)4K 테스트 환경을 먼저 해제:
umount /oradata4k
vgchange -an vg_data4k
losetup -d /dev/loop0사용 프로세스 확인:
fuser -vm /data1아래처럼 kernel mount만 남아 있으면 일반 사용자 프로세스가 파일시스템을 점유하고 있지는 않은 상태다.
/data1: root kernel mount /data1아직 댓글이 없습니다. 이 글에서 얻은 생각이나 질문을 남겨보세요.
로그인하고 댓글 남기기 →기존 stop timeout 때문에 다음 상태가 발생할 수 있다.
fs_data FAILED oel19PA (disabled, blocked)이 상태에서 /data1이 여전히 mount되어 있다면 실제 파일시스템을 수동으로 내린다.
cd /
umount /data1확인:
findmnt /data1
df -Thfindmnt /data1 결과가 없어야 한다.
아직 댓글이 없습니다. 이 글에서 얻은 생각이나 질문을 남겨보세요.
로그인하고 댓글 남기기 →실제 대상 LV에 먼저 -n 옵션으로 점검한다.
xfs_repair -n /dev/mapper/vg_data-lv_data실제 확인된 오류:
imap claims a free inode 169 is in use, would correct imap and clear inode
entry "WSMAINDB_1_2_1235437312.arc" in shortform directory 166 references free inode 169
would have junked entry "WSMAINDB_1_2_1235437312.arc" in directory inode 166디렉터리 inode 166에는 WSMAINDB_1_2_1235437312.arc 엔트리가 남아 있음
해당 엔트리가 inode 169를 가리키고 있음
하지만 inode 169는 이미 free 상태임
즉 디렉터리 엔트리와 inode allocation 정보가 불일치
이 때문에 ls가 파일의 stat 정보를 읽지 못해 -??????????로 표시됨
아직 댓글이 없습니다. 이 글에서 얻은 생각이나 질문을 남겨보세요.
로그인하고 댓글 남기기 →파일시스템이 unmount된 상태에서 실행:
xfs_repair /dev/mapper/vg_data-lv_data실제 복구 메시지:
imap claims a free inode 169 is in use, correcting imap and clearing inode
cleared inode 169
entry "WSMAINDB_1_2_1235437312.arc" in shortform directory 166 references free inode 169
junking entry "WSMAINDB_1_2_1235437312.arc" in directory inode 166마지막:
Phase 7 - verify and correct link counts...
donexfs_repair가 다음을 수행했다.
잘못된 inode allocation map 수정
free 상태인 inode 169 정리
inode 169를 가리키던 깨진 directory entry 제거
AG header/tree 및 link count 재검증
따라서 기존 -?????????? 파일 엔트리는 제거된다.
아직 댓글이 없습니다. 이 글에서 얻은 생각이나 질문을 남겨보세요.
로그인하고 댓글 남기기 →복구 후 실패 상태 정리:
pcs resource cleanup fs_data필요 시 unmanaged 상태 해제:
pcs resource manage fs_data리소스 활성화:
pcs resource enable fs_data --wait=60최종 확인:
pcs status
findmnt /data1
ls -la /data1/19c/arch최종 정상 상태 예:
fs_data Started oel19PA
fs_arch Started oel19PA
vip_oracle Started oel19PA
ora_lsnr Started oel19PA/data1 /dev/mapper/vg_data-lv_data xfs rw,...아직 댓글이 없습니다. 이 글에서 얻은 생각이나 질문을 남겨보세요.
로그인하고 댓글 남기기 →XFS repair를 위해 /data1/disk4k.img의 loop 연결을 해제했으므로 4K 테스트를 계속할 경우 다시 연결한다.
이 글의 노션 원문 ↗XFS repair를 위해 /data1/disk4k.img의 loop 연결을 해제했으므로 4K 테스트를 계속할 경우 다시 연결한다.
losetup -f --show --sector-size 4096 /data1/disk4k.img
vgchange -ay vg_data4k
mount /dev/vg_data4k/lv_data4k /oradata4k확인:
lsblk -o NAME,TYPE,SIZE,PHY-SEC,LOG-SEC
df -hT /oradata4k목표 상태:
loop0 loop 10G 4096 4096
└─vg_data4k-lv_data4k lvm 9G 4096 4096아직 댓글이 없습니다. 이 글에서 얻은 생각이나 질문을 남겨보세요.
로그인하고 댓글 남기기 →ls에서 -?????????? 파일 확인
↓
문제 파일이 위치한 실제 mount/LV 확인
↓
Pacemaker Filesystem 리소스 disable
↓
stop timeout 발생 시 파일시스템 점유 요소 확인
↓
4K loop backing file 및 관련 LVM 해제
↓
/data1 수동 unmount
↓
xfs_repair -n 으로 오류 확인
↓
xfs_repair 실제 수행
↓
깨진 inode / directory entry 정리
↓
Pacemaker cleanup / enable
↓
mount 및 파일 상태 최종 확인아직 댓글이 없습니다. 이 글에서 얻은 생각이나 질문을 남겨보세요.
로그인하고 댓글 남기기 →이번 장애의 직접 원인은 WSMAINDB_1_2_1235437312.arc 디렉터리 엔트리가 이미 free 상태인 inode 169를 참조하고 있던 XFS 메타데이터 불일치였다. rm -rf 옵션 문제가 아니며, 올바른 해결 방법은 해당 파일시스템을 unmount한 뒤 xfs_repair로 inode 및 directory
이 글의 노션 원문 ↗이번 장애의 직접 원인은 WSMAINDB_1_2_1235437312.arc 디렉터리 엔트리가 이미 free 상태인 inode 169를 참조하고 있던 XFS 메타데이터 불일치였다. rm -rf 옵션 문제가 아니며, 올바른 해결 방법은 해당 파일시스템을 unmount한 뒤 xfs_repair로 inode 및 directory entry를 복구하는 것이다.
Pacemaker에서 Filesystem 리소스로 관리하는 mount point는 수동 umount만으로 처리하면 클러스터가 다시 mount할 수 있다. 반드시 해당 fs_* 리소스를 먼저 disable하고 작업해야 한다.
아직 댓글이 없습니다. 이 글에서 얻은 생각이나 질문을 남겨보세요.
로그인하고 댓글 남기기 →공개 노션 링크 하나면 목차가 있는 스터디가 됩니다.
아직 댓글이 없습니다. 이 글에서 얻은 생각이나 질문을 남겨보세요.