우분투 서버 : "x"파일을 삭제할 수 없습니다. 구조체를 정리해야합니다.

나는 우분투 서버 16.04에서 호스팅되는 게임 서버를 가지고 있으며 다음 파일 때문에 파란색을 시작할 수 없거나 다시 시작할 수 없습니다.

-????????? ? ?     ?        ?            ? proceduralmap.3000.1499245715.149.sav

이것은이 상황에서 fs의 유일한 파일 인 것 같습니다. 이제 서버는 호스팅 제공 업체에서 구입 한 전용 서버입니다. 파일이있는 드라이브는 SCSI로 마운트 된 HDD입니다 ( /dev/sdb1 ).

그만큼 df -hT 산출:

Filesystem     Type      Size  Used Avail Use% Mounted on
udev           devtmpfs  3.7G     0  3.7G   0% /dev
tmpfs          tmpfs     744M   81M  663M  11% /run
/dev/sda4      ext4       21G   16G  4.7G  77% /
tmpfs          tmpfs     3.7G   24K  3.7G   1% /dev/shm
tmpfs          tmpfs     5.0M     0  5.0M   0% /run/lock
tmpfs          tmpfs     3.7G     0  3.7G   0% /sys/fs/cgroup
/dev/sda3      ext4      946M  143M  739M  17% /boot
cgmfs          tmpfs     100K     0  100K   0% /run/cgmanager/fs
/dev/sdb1      ext2      985G  265G  670G  29% /storage
tmpfs          tmpfs     744M     0  744M   0% /run/user/1011

해당 파일을 복구 / 제거하는 적절한 방법은 무엇입니까? 나는 그것을 수리하는 것을 선호 할 것이지만 제거는 또한 할 것이다. 나는 이미 달렸다.

debugfs -w /dev/sdb1

내가 입력 한 내용 :

clri home/steam/serverfiles/server/rustserver/proceduralmap.3000.1499245715.149.sav

웹에서 찾을 수있는 것부터 e2fsck를 실행해야한다는 것을 이해하지만 드라이브를 먼저 마운트 해제해야한다는 것을 이해합니다. 가능하다면이 하나의 파일에 대해서만 그렇게하고 싶지는 않을 것입니다.

감사!

"구조가 지워 져야 함"오류 메시지

"구조체 제거 필요"오류는 파일 시스템 손상 (특히 ext4 및 xfs)이 파일 시스템 손상 문제를 감지했을 때 반환되는 오류입니다. 불행히도 손상을 복구하는 유일한 방법은 디스크를 마운트 해제하고 실행하는 것입니다. e2fsck 파일 시스템에서. (기술적으로, 당신은 -f 옵션은 파일 시스템이 이미 문제점을 감지했으며 파일 시스템이 문제가 있음을 표시했기 때문에 선택 사항입니다. 그래서 당신이 달릴 때 e2fsck 이러한 문제를 해결하기 위해 전체 검사를 수행 할 것이므로 -f 옵션을 사용하여 강제로 확인하십시오.)

파일 시스템 손상보고

또한 커널 로그를보고 파일 시스템 손상 보고서를 볼 수 있어야합니다. (예 : dmesg, 또는보고 /var/log/kern.log 어디서나 syslog 또는 journald 커널 메시지를 기록하도록 구성되었습니다. 시작하는 메시지가 표시되어야합니다. EXT4-fs error (device sdXX). 예 :

EXT4-fs error (device sda3): ext4_lookup:1602: inode #37005: comm docker: deleted inode referenced: 31872136

또한 오류를 표시함으로써 오류 표시를 볼 수 있습니다. dumpe2fs -h 파일 시스템에서. 관심 분야 :

FS Error count:           25

이것은 커널이 파일 시스템 불일치를 25 번 발견했다는 것을 의미합니다.

First error time:         Thu Jan  1 12:19:59 2015
First error function:     ext4_ext_find_extent
First error line #:       400
First error inode #:      95223833
First error block #:      0

첫 번째 오류는 지정된 시간에 2015 년 1 월 1 일에 발견되었습니다. 오류 함수 및 행 번호를 사용하면 커널 코드의 어느 부분에서 문제점을 발견했는지 정확하게 식별 할 수 있습니다. inode #는 파일 시스템 불일치와 관련된 inode를 알려줍니다.

Last error time:          Wed Feb  4 11:57:05 2015
Last error function:      ext4_ext_find_extent
Last error line #:        400
Last error inode #:       95223833
Last error block #:       0

이것은 커널이 파일 시스템 불일치를 발견 한 가장 최근의 시간을 알려줍니다. 이 두 시간 사이의 큰 델타는 어떤 사람 커널 메시지를 검사하지 않았습니다. 그것은 24 시간마다 ext4가 손상된 파일 시스템이 있다는 경고 메시지를 기록하고 커널 메시지가 다음과 같이 표시되기 때문입니다.

EXT4-fs (dm-0): error count since last fsck: 12
EXT4-fs (dm-0): initial error at time 1441536566: ext4_dirty_inode:4655
EXT4-fs (dm-0): last error at time 1441537273: ext4_remount:4550

참고 : 커널 메시지의 시간은 UTC 1970 년 1 월 1 일 자정부터 초 수입니다. 예를 들어, date 명령을 사용하여이를 사람이 읽을 수있는 시간으로 변환 할 수 있습니다.

% date -d @1441536566
Sun Sep  6 06:49:26 EDT 2015

파일 시스템이 손상되었다는 것을 알게되었을 때해야 할 일

더 많은 데이터 손실을 초래할 수 있으므로 파일 시스템 불일치로 실행하고 싶지 않습니다. 이러한 보고서에 뛰어 들고 필요할 경우 중단 시간을 계획하고 최대한 빨리 수정하는 것이 좋습니다.

이유는 무엇 e2fsck 장치를 마운트 해제 한 후 장치가 사용중이라고 불평합니까?

마지막으로, 귀하의 질문에 대한 답변 : "나는 달렸다. fsck 마운트 해제 후 다음 오류가 발생합니다. /dev/sdb1 is in use. 어떤 생각입니까? "대체 마운트 네임 스페이스에 하나 이상의 프로세스가 있고 그 프로세스가 여전히있을 수 있습니다. /dev/sdb1 마운트 이름 공간에 마운트됩니다. 시도해 볼 수도 있습니다.

grep /dev/sdb1 /proc/*/mounts

대체 마운트 네임 스페이스에서 실행중인 프로세스를 찾으면 가장 간단한 방법은 해당 프로세스를 종료하고 다시 시작하는 것입니다. (아마도 데몬 프로세스 일 것입니다.) 마운트 네임 스페이스를 사용하는 마지막 프로세스가 종료되면 마운트 이름 공간이 사라집니다. 그리고 일단 마운트 네임 스페이스가 없으면 /dev/sdb1 마운트, 그것은 진짜로 진짜로 unmounted 것입니다.

이것에 대해 생각하는 방법은 umount ~처럼 행동하다 unlink. 하드 링크가 여러 개인 파일이있는 경우 마지막 하드 링크가 삭제 될 때만 공간이 해제됩니다. 네임 스페이스가 여러 개 활성화되어있는 경우 각 네임 스페이스는 문제의 마운트에 대한 "하드 링크"역할을합니다. 따라서 일부 프로세스가 기본 마운트 네임 스페이스를 분기하고 상위 마운트 네임 스페이스의 복사시 복사 (copy-on-write) 복사본에서 자체 및 일부 하위 프로세스를 실행중인 경우 기본 마운트 네임 스페이스에서 파일 시스템을 마운트 해제하는 것만으로는 도움이되지 않습니다.