파일을 이동할 때 파일 시스템이 중단되면 파일 시스템이 일치하지 않을 수 있습니까?


13

동일한 파티션 (EXT2)에 두 개의 폴더가 있습니다. 만약 내가 mv folder1/file folder2어떤 장애가 발생하면 (예 : 정전) 파일 시스템이 일관되지 않을 수 있습니까?

하지 않 mv작업이 원자?

업데이트 : 지금까지 IRC에서 다음과 같은 관점을 얻었습니다.

  1. 원 자성이므로 불일치가 발생할 수 없습니다
  2. 먼저 새 디렉토리에 dir 항목을 복사 한 다음 이전 디렉토리에 대한 항목을 지우므로 파일이 두 번 참조되는 불일치가 발생할 수 있지만 참조 횟수는 1입니다.
  3. 먼저 포인터를 지우고 포인터를 복사하여 파일이 참조 0을 갖지 않도록합니다.

누군가가 명확히 할 수 있습니까?

답변:


11

먼저 신화를 버리자.

원 자성이므로 불일치가 발생할 수 없습니다

동일한 파일 시스템 (예 :) rename시스템 호출 내에서 파일을 이동하는 것은 소프트웨어 환경과 관련하여 원 자성입니다. 원자 성은 파일을 찾는 모든 프로세스가 이전 위치 또는 새 위치에서 파일을 볼 수 있음을 의미합니다. 프로세스가 파일의 링크 수가 다른지 또는 대상 디렉토리에있는 파일이 소스 디렉토리에 있거나 소스에없는 파일이 대상 디렉토리에없는 것을 관찰 할 수 없습니다. 예배 규칙서.

그러나 버그, 디스크 오류 또는 전원 손실로 인해 시스템이 충돌하는 경우 파일 시스템이 일관된 상태로 유지된다고 보장 할 수는 없습니다. Linux는 일반적으로 하드웨어 이벤트와 관련하여 원 자성을 보장하지 않습니다.

먼저 새 디렉토리에 dir 항목을 복사 한 다음 이전 디렉토리에 대한 항목을 지우므로 파일이 두 번 참조되는 불일치가 발생할 수 있지만 참조 횟수는 1입니다.

이것은 특정 구현 기술을 나타냅니다. 다른 것도 있습니다.

그것은 그래서 어떻게 리눅스의 ext2을 (커널 3.16 현재)이 특정 기술을 사용합니다. 그러나 이는 두 개의 작업 (새 항목 추가, 이전 항목 제거)이 하드웨어 수준에서도 원자 적이 지 않기 때문에 디스크 내용이 [이전 위치] → [두 위치] → [새 위치] 순서를 거치는 것을 의미하지는 않습니다. : 파일 시스템 중 하나가 중단되어 파일 시스템이 일치하지 않는 상태가 될 수 있습니다. (fsck가이를 복구 할 수 있기를 바랍니다.) 또한 블록 계층은 쓰기 순서를 바꿀 수 있으므로 충돌의 직전 절반이 디스크에 커밋되고 나머지 절반은 수행되지 않을 수 있습니다.

시스템이 충돌하지 않는 한 (위 참조) 시스템 카운트로 확장되지 않는 한 참조 카운트는 1과 다른 것으로 절대 관찰되지 않습니다.

먼저 포인터를 지우고 포인터를 복사하여 파일이 참조 0을 갖지 않도록합니다.

다시 한 번, 이는 특정 구현 기술을 나타냅니다. 시스템이 충돌하지 않으면 매달린 파일을 관찰 할 수 없지만 적어도 일부 구성에서는 시스템 충돌의 결과 일 수 있습니다.


Alexander Larsson의 블로그 게시물에 따르면 ext2는 시스템 충돌에 대한 일관성을 보장하지 않지만 ext3는 data=ordered모드 에서 작동합니다. (이 블로그 게시물은 rename그 자체가 아니라 파일에 쓰고 파일을 호출하는 조합에 rename관한 것입니다.)

ext2, ext3 및 ext4 파일 시스템의 주요 저자 인 Theodore Ts'o 는 같은 문제에 대한 블로그 게시물을 작성했습니다 . 이 블로그 게시물은 원 자성 (소프트웨어 환경에 대해서만)과 내구성 (충돌에 대한 원 자성 및 약속 보장, 즉 작업이 수행되었음을 알고 있음)에 대해 설명합니다. 불행히도 충돌 자체와 관련하여 원자성에 대한 정보를 찾을 수 없습니다. 그러나 ext4에 제공되는 내구성 보증 rename은 원 자성을 요구합니다 . 된 ext4에 대한 커널 문서 상태는와 ext4가 있음을 auto_da_alloc뿐만 아니라, ext4에 (현대 커널에 기본값) 옵션은 대한 내구성 보증 제공 writea로 다음을renamerename하드웨어 충돌과 관련하여 원자적임 을 의미합니다 .

BTRFS를 들어, 기존 파일을 덮어 씁니다은 충돌에 대한 원자 보장되지만 파일을 덮어 쓰지 않습니다 그 어느 파일이나 기존의 두 파일이 발생할 수 있습니다.renamerename


요약하면, 귀하의 질문에 대한 답변은 ext2의 충돌과 관련하여 원자가 아닌 파일을 이동시킬뿐만 아니라 파일을 일관된 상태로 유지한다고 보장 할 fsck수 없다는 것입니다. 더 좋은 파일 시스템이 발명 된 이유는 거의 없습니다. Ext3, ext4 및 btrfs는 제한된 보증을 제공합니다.


13

가 중단 될 가능성이 있지만, 고전적인 파일 시스템에 확실히 때문에 이름 바꾸기 작업은, 어떤 파일 시스템에 매우 빠르게 할 수 있습니다 먼저 대상 링크를 생성하는 경우,이 파일에 두 개의 링크 떠날 수 - - 법적, 중단 그러나 파일에는 파일 이 하나만 있다고 생각 하여 나중에 삭제하면 문제가 발생할 수 있습니다. 반면에 소스 링크를 먼저 제거하면 파일이 손실 될 수 있습니다. fsck를 실행하면 파일을 잃어버린 경우 원하는 위치가 아닌 임의의 이름으로 "잃어버린 + 찾은"디렉토리에 배치됩니다. 링크가 두 개인 경우 링크 수는 단순히 파일 시스템이이를 지원하는 경우 파일이 두 위치에 존재합니다.

정전시 파일 시스템이 견고 해야하는 경우 NTFS, EXT3 또는 XFS와 같은 저널링 파일 시스템을 사용해야합니다 . 대부분의 최신 시스템은 기본적으로 저널링 파일 시스템을 사용하지만 FAT를 외부 드라이브에 사용하는 경우 FAT는 저널링 파일 시스템이 아님을 알아야합니다.

저널링 파일 시스템은 "이중 항목"시스템을 사용합니다. 저널 파일에 이동하려는 사실을 저널 파일에 쓴 다음 이동을 수행합니다. 시작시 파일 시스템을 검사 할 때 중단 된 경우 이동이 완료되지 않았 음을 확인한 다음 다시 실행합니다.

저널링 파일 시스템에는 메타 데이터 저널링과 전체 저널링의 두 가지 유형이 있습니다. 메타 데이터 저널링은 저널 시스템의 파일 내용에 대한 변경 내용을 추적하지 않으므로 (파일에 쓰면 내용이 손실 될 수 있음) 디렉토리 내용과 같은 중요한 파일 시스템 정보는 계속 추적 함을 의미합니다. , 파일 속성 등


사람들이 이름 바꾸기 작업을 원 자성이라고 말하면 시스템의 다른 프로세스에서 전환 도중에 관찰 할 수 없으며 예를 들어 mv명령 자체를 중단하여 반쯤 완료 할 수는 없습니다 ^C. 스토리지 공간이 디스크의 광범위하게 다른 위치에있을 수있는 각 디렉토리에 대한 실제 쓰기 프로세스는 하드웨어 수준에서 진정한 원자 작업이 될 수 없습니다.


완성도를 높이기 위해 대상 디렉토리에 새 링크를 만들고 이전 디렉토리에서 링크를 제거하는 것 외에도 이름 바꾸기와 관련된 부수적 인 I / O 작업도 있습니다. 두 디렉토리의 mtime을 업데이트하여 ..파일이 디렉토리 인 경우 대상 디렉토리의 할당 크기, 링크 및 상위 디렉토리의 링크 수를 변경합니다 . 또한 파일 자체의 시간이 영향을 받는지 확실하지 않습니다.


저널은 원 자성 wrt 정전을 보장하지 않습니다. 나는 ext3과 ext4 rename가 원 자성을 보장한다고 생각 하지만 btrfs는 위키에 따르지 않습니다 (내 대답 참조). 저널없이 원 자성을 보장하는 것도 가능하다 (리눅스의 예제는 모르지만 일부는있을 수있다). ext2에 대한 신뢰할 수있는 정보가 있습니까?
Gilles 'SO- 악의를 그만두십시오'

@Gilles 저널없이 이론적으로 보장 할 수있는 방법에 대한 정보가 있습니까? 기본 수준에서 두 파일을 서로 동기화하여 파일 중 하나만 수행 한 결과를 얻지 못하도록하는 것을 말합니다.
Random832

로그 구조 파일 시스템 은 사용중인 블록을 덮어 쓰지 않음으로써 일관성을 유지합니다. 기존 데이터 덮어 쓰기 비용이 많이 드는 플래시 미디어에 적합합니다. 마운트 할 때 아무 것도 재생되지 않기 때문에 로그는 실제로 저널과 같지 않습니다. 그러나 전체 파일 시스템이 저널이라고 말할 수 있습니다 (마운트가 너무 느려서 메모리에있는 모든 것을 재생하는 것을 제외하고는 제외). Wikipedia 의 LogFS 에 대한 설명은 좋은 개요입니다.
Gilles 'SO- 악마 그만

1

이 질문 슈퍼 유저에 대해 약간 다른 방식으로 요청되었습니다 . mv명령 의 Wikipedia 페이지 에서도 다음과 같이 설명합니다 .

동일한 파일 시스템 내에서 파일 이동은 일반적으로 파일을 복사 한 다음 원본을 제거하는 것과 다르게 구현됩니다. syscall 이름 바꾸기를 지원하지 않는 플랫폼에서는 새 링크가 새 디렉토리에 추가되고 원래 디렉토리는 삭제됩니다. 파일의 데이터에 액세스하지 않습니다.

리눅스는 syscall 이라는 이름을 가지고 있기 때문에 파일의 이름을 원자 적, 즉 상호 운용 불가능한 작업으로 바꿉니다. 따라서 설명하지 않은 상황에서 파일 시스템이 일치하지 않을 수 없습니다.


2
이름 바꾸기 시스템은 OS 추상화를 호출합니까? 이름 바꾸기는 일련의 작업해야하기 때문에 현명한 하드웨어, 난 항상 일련의 조작을 방해 할 수 있기 때문에
graphtheory92

아니요, OS 추상화는 아니지만 "파일 시스템이 일치하지 않을 가능성이 매우 낮습니다."라고 말하면 일이 지나치게 복잡해질 것입니다. 그래도 동의합니다.
Benjamin B.

2
이 답변은 rename 정전이 발생하더라도 시스템 호출로 인해 파일 시스템이 불일치 상태가 될 수 없는지 궁금 합니다 . 이것이 @ graphtheory92의 질문의 핵심이라고 생각했습니다.
Tanner Swett

1
@ graphtheory92 : 시스템 호출이 원자 적이라고해서 결과 디스크 조작 (또는 일련의 디스크 조작!)도 원자 적이라는 의미는 아닙니다. ------ 파일을 이동 (하드 링크 수 1)하고 전원, 하드 디스크 연결을 끊거나 적시에 커널을 충돌 시키면 두 개의 하드 링크 (원본 및 새 링크)가 생길 수 있습니다. ) 하드 링크 카운트가 여전히 1 인 파일에 문제가 있습니다. ------ 문제에 대한 두 가지 기본 솔루션이 있다고 생각합니다. b) 하드웨어 지원 거래.
pabouk

2
원자성에 대한 보장은 다른 프로세스의 관찰과 관련이 있습니다. 시스템 충돌시 보류되지 않습니다.
Gilles 'SO- 악의를 그만두십시오'
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.