lost + found를 삭제하면 어떻게됩니까


38

ext3과 같은 일부 Linux 파일 시스템을 만들면 'lost + found'디렉토리가 생성됩니다. 파일 에 따르면 어떤 종류의 시스템 충돌로 인해 파일이 손상된 경우 거기에 배치됩니다.

이 디렉토리가 제거되고 시스템이 충돌하면 어떻게됩니까? 폴더가 제거되면 mkdir lost + found 로 새 디렉토리를 만들 거나 파일 시스템을 만들 때만 설정할 수있는 속성이 있습니다.

답변:


35

fsck는 lost + found 디렉토리가없는 경우 다시 작성합니다.

시작시 파일 시스템이 완전히 마운트 해제되지 않은 것으로 감지되면 대부분의 분배는 fsck를 실행합니다. fsck는 lost + found 디렉토리가 누락 된 경우이를 작성하면이를 작성하여 찾은 것을 해당 디렉토리에 배치합니다.


15

실행할 수 없거나 실행하지 않으려는 fsck경우 다음을 사용하여 lost+found디렉토리를 다시 만들 수 있습니다 mklost+found.

mklost + found는 파일 블록을 복구하기 위해 e2fsck (8)가 실행될 때 많은 수의 링크되지 않은 파일을 저장하기 위해 파일 시스템에 블록을 할당 할 필요가 없도록 디스크 블록을 lost + found 디렉토리에 사전 할당합니다. 이를 통해 e2fsck가 복구 중에 파일 시스템에 데이터 블록을 할당하지 않아도됩니다.


RHEL 6.4에서 나 fscke2fsck다시 만드는 날 위해는 상관없이 디렉토리가 마운트하거나하지 않은 경우 곳. cd <root-dir-of-the-mount> && mklost+found그것을했다.
Luis Antolín Cano

7

링크되지 않은 많은 파일을 포함하기에 충분한 크기를 가진 기존의 lost + found 디렉토리는 디렉토리를 작성하고 적절한 크기로 늘리는 e2fsck의 부담을 덜어줍니다.

여전히 그렇게하려고 시도하지만 손상된 파일 시스템에 직면하면 더 위험 할 수 있습니다.

다른 플랫폼의 다른 파일 시스템에 대한 아주 오래된 fsck는 / lost + found를 만들거나 확장 할 수 없었습니다. 이것은 / lost + found의 근거에 대한 역사입니다. 그러나 현재의 이론적 근거는 단순히 e2fsck의 작업을 더 쉽게 만드는 것입니다.


4
이들이 lost + found를 작성할 수 없었던 것은 아닙니다. 이미 망가진 파일 시스템에 파일 / 디렉토리를 작성하는 것은 나쁜 생각입니다. 대신, 정리하려고 할 때 망가진 파일 시스템에서 찾은 멍청한 inode의 디렉토리 항목을 저장할 수있을만큼 이미 큰 디렉토리를 미리 빌드하면됩니다.
chris

5

당신이 no lost+found이면 e2fsck(다른 fsck구현에 대한 코드를 검사하지 않았습니다 ) 당신을 위해 그것을 제안 할 것입니다. 그러나 원하는 경우 직접 다시 만들 수도 있습니다. 그 디렉토리에는 특별한 것이 없습니다 (적어도 코드 검사는 아닙니다).


2
필요한 경우 fsck가 lost + found를 다시 만들어야합니까?
David Schmitt

2
감사합니다. e2fsck의 코드를 확인했으며 실제로 코드를 다시 만들도록 제안합니다. (이것은 성공을 보장하지는 않습니다. 그래서 미리 작성된 lost + found도 유용합니다.) 깔끔합니다!
Chris Jester-Young

6
@ ChrisJester-Young-답변이 잘못되었습니다. lost+found특별한 디렉토리입니다. 복구 도구가 복구 중에 블록을 할당 할 필요가 없도록 사전 할당 된 디스크 블록이 있습니다. 도구 가 제대로 생성되지 mklost+found않기 때문에 특별히 존재하는 도구 mkdir입니다. linux.die.net/man/8/mklost+found
Aggregation1166877

2

e2fsck는 lost + found를 다시 작성하고 동일한 이름을 가진 파일을 삭제하여 디렉토리로 작성할 수 있도록합니다.

이전의 많은 유닉스 파일 시스템에서는 lost + found를 특히 inode 2 번에 첨부해야하므로 디렉토리가 손실 된 경우 대부분의 경우 파일 시스템을 다시 작성해야합니다. e2fsck는 단순히 inode 2를 필요로하지 않는 임의의 free inode를 검색하기 때문에 이전보다 훨씬 간단하게 복구 할 수 있습니다.


1

mkdir을 사용하여 해당 디렉토리를 작성할 수 있습니다. 루트 또는 휠 그룹으로 루트가 소유해야합니다. 그 외에는 특별한 점이 없습니다. 시스템이 부팅 될 때 정전 또는 부적절한 종료가 발생하면 자동으로 fsck를 시작해야합니다. fsck는 시스템을 통해 발견 된 손상된 파일을 복구하려고 시도합니다. 손상 가능성이있는 파일은 그곳으로 이동합니다.

fsck가 상위 inode가없는 파일을 찾은 경우 파일이 이동되는 다른 경우가 있습니다. 이것은 일반적으로 폴더의 inode가 저장되는 특정 위치의 디스크에서 블록이 손상되는 경우입니다. 부모 inode를 lost + found 폴더로 다시 할당합니다.

편집 : 후자의 경우 디렉토리를 다시 만들지 확실하지 않습니다. 나는 안전한 편이되도록 내버려 두었습니다. 삭제해야 할 이유가 없습니다. 그것 없이는 아무 나쁜 일도 일어나지 않을 것입니다.


1
당신은 확신 단지로 만들 괜찮아 mkdir?

예, 공간 할당은 디렉토리 inode 또는 경로와 연결되어 있지 않습니다. 예약 된 공간 할당은 일부 메모리에서 루트 / 커널 권한과 fsck가 알고있는 액세스를위한 특수 호출이 필요한 플래그보다 적습니다. 잠재적으로 손상되었거나 손상된 파일을 해당 메모리에 복사하여 해당 공간을 사용합니다. inode가 새 메모리를 가리키는 파일. 파일 작업은 해당 파일에서 정상적으로 작동하지만 이동 또는 저장과 같은 변경 사항은 예약 된 메모리에서 데이터를 가져옵니다.
TrueDuality

1

또한 데비안 6 및 Ubuntu 12 LTS에서는 로컬 파일 시스템에서 누락 된 디렉토리를 확인하고 전자 메일을 통해 매일 알리미를 보내도록 권장하는 cron패키지가 배송 /etc/cron.daily/standard되었습니다 .lost+foundmklost+found

그러나 이것은 데비안 7과 우분투 14 LTS 시대에 폐기되었습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.