파일 변경 사항이 디스크에 직접 저장되었다고 생각 했었습니다. 즉, 파일을 닫고 저장을 클릭 / 선택하기로 결정하자마자. 그러나 최근 대화에서 내 친구가 보통 그렇지 않다고 말했습니다. OS (특히 Linux 시스템에 대해 이야기하고 있음)는 메모리의 변경 사항을 유지하며 실제로 메모리에서 디스크로 내용을 쓰는 데몬이 있습니다.

그는 외부 플래시 드라이브의 예를 보여주었습니다. 이것들은 시스템에 마운트되고 (메모리에 복사 됨) 데몬이 아직 플래시 메모리에 내용을 저장하지 않았기 때문에 데이터 손실이 발생합니다. 이것이 플래시 드라이브를 마운트 해제하는 이유입니다.

운영 체제 기능에 대한 지식이 없으므로 이것이 사실인지 어떤 상황인지 전혀 알 수 없습니다. 내 주요 질문은 : Linux / Unix 시스템 (및 다른 OS)에서 설명한 것처럼 발생합니까? 예를 들어, 파일을 편집하고 저장 한 직후 에 컴퓨터를 끄면 변경 사항이 손실 될 가능성이 큽니까? 아마도 기존 하드 드라이브와 솔리드 스테이트 디스크 중 어떤 디스크 유형에 따라 달라질 수 있습니까?

이 질문은 설명이나 비교가 잘 되더라도 정보를 저장할 디스크가있는 파일 시스템과 관련이 있습니다.

파일을 편집하고 저장 한 후 즉시 컴퓨터를 끄면 변경 내용이 손실 될 가능성이 가장 큽니까?

그럴 수도 있습니다. 나는 "가장 가능성이 높다"고 말하지는 않지만 그 가능성은 많은 것들에 달려 있습니다.

파일 쓰기 성능을 향상시키는 쉬운 방법은 OS가 데이터를 캐시하고 쓰기가 진행된 응용 프로그램에 알리고 실제로 쓰기를 수행하는 것입니다. 이것은 다른 디스크 작업이 동시에 진행되는 경우에 특히 유용합니다. OS가 읽기 우선 순위를 지정하고 나중에 쓰기를 수행 할 수 있습니다. 예를 들어, 임시 파일이 나중에 빠르게 제거되는 경우와 같이 실제 쓰기의 필요성을 완전히 제거 할 수도 있습니다.

저장 속도가 느리면 캐싱 문제가 더 두드러집니다. USB 스틱을 유지할 수 없기 때문에 빠른 SSD에서 느린 USB 스틱으로 파일을 복사하면 많은 쓰기 캐싱이 필요할 수 있습니다. 그러나 cp명령이 더 빨리 반환되므로 작업을 계속할 수 있으며 방금 복사 한 파일을 편집 할 수도 있습니다.

물론 캐싱에는 단점이 있지만 실제로 저장하기 전에 일부 데이터가 손실 될 수 있습니다. 편집기에서 쓰기에 성공했다고 말했지만 실제로 파일이 디스크에 있지 않은 경우 사용자가 소리를냅니다. 그렇기 때문에 파일이 실제로 디스크에 닿은 후에 만 ​​리턴되는 fsync()시스템 호출 이 있습니다. 편집자는이를 사용하여 쓰기에 성공했음을 사용자에게보고하기 전에이를 사용하여 데이터가 올바른지 확인할 수 있습니다.

드라이브 자체가 OS에 동일한 거짓말을하고 쓰기가 완료되었다고 말할 수 있기 때문에 파일은 실제로 드라이브 내의 휘발성 쓰기 캐시에만 존재하기 때문에 "해야한다"고 말했다. 드라이브에 따라 주변에 방법이 없을 수 있습니다.

이외에도 시스템 전체에서 특정 파일 시스템의 모든 쓰기 또는 모든 쓰기가 디스크에 닿도록 시스템에 요청 fsync()하는 sync()및 syncfs()시스템 호출이 있습니다. 유틸리티 sync를 사용하여이를 호출 할 수 있습니다.

그리고 "에 대한 I / O의 캐시 효과를 최소화하려고합니다" O_DIRECT플래그가open() 있습니다. 캐싱을 제거하면 성능이 저하되므로 자체 캐싱을 수행하고 제어하려는 응용 프로그램 (데이터베이스)에서 주로 사용됩니다. ( O_DIRECT문제가없는 것은 아니지만 맨 페이지의 의견은 다소 재미 있습니다.)

전원이 꺼지면 파일 시스템에 따라 달라집니다. 걱정해야 할 파일 데이터뿐만 아니라 파일 시스템 메타 데이터입니다. 디스크에 파일 데이터가 있으면 찾을 수 없으면 많이 사용되지 않습니다. 파일을 더 큰 크기로 확장하기 만하면 새로운 데이터 블록을 할당해야하며 어딘가에 표시해야합니다.

파일 시스템이 메타 데이터 변경을 처리하고 메타 데이터와 데이터 쓰기 간의 순서는 매우 다양합니다. 예를 들어, ext4를 사용하여 mount 플래그를 설정하면 data=journal모든 쓰기 (데이터 쓰기도 포함)가 저널을 통과하므로 다소 안전해야합니다. 또한 두 번 작성되므로 성능이 저하됩니다. 기본 옵션은 메타 데이터가 업데이트되기 전에 데이터가 디스크에 있도록 쓰기 순서를 지정합니다. 다른 옵션이나 다른 파일 시스템이 더 좋거나 나쁠 수 있습니다. 나는 종합적인 연구조차 시도하지 않을 것입니다.

실제로 약간로드 된 시스템에서는 파일이 몇 초 내에 디스크에 닿아 야합니다. 이동식 저장 장치를 다루는 경우 미디어를 가져 오기 전에 파일 시스템을 마운트 해제하여 실제로 데이터가 드라이브로 전송되는지 확인하십시오. 그러면 더 이상 활동이 없습니다. 또는 GUI 환경에서이를 수행하도록하십시오.

이 매우 는 것을 증명하는 간단한 방법 할 수없는 파일 편집이 항상 직접 디스크에 파일 시스템이 있다는 것을, 즉 사실에 저장됩니다 사실 처음에 디스크로 백업되지 않습니다는 . 파일 시스템이없는 경우 가 처음에 디스크를, 그것은 아마도 수 없습니다 , 변경 사항을 디스크에 쓰기 이제까지 .

몇 가지 예는 다음과 같습니다.

• tmpfsRAM에만 존재하는 파일 시스템 (보다 정확하게는 버퍼 캐시)
• ramfsRAM에만 존재하는 파일 시스템
• 모든 네트워크 파일 시스템 (NFS, CIFS / SMB, AFS, AFP 등)
• 어떤 가상 파일 시스템 ( sysfs, procfs, devfs, shmfs, ...)

그러나 디스크 백업 파일 시스템의 경우에도 이것은 사실이 아닙니다. SQLite 데이터베이스 손상 방법 페이지 에는 쓰기 실패 (이 경우 SQLite 데이터베이스에 커밋)가 디스크에 도달하지 못하는 여러 가지 방법을 설명 하는 동기화 실패 라는 장이 있습니다. SQLite는 또한 SQLite에서 Atomic Commit 을 보장하기 위해 뛰어야하는 많은 후프를 설명하는 백서를 가지고 있습니다 . (참고 원자 쓰기는 단지보다는 문제보다 훨씬 어렵 쓰기 ,하지만 물론 디스크에 쓰기는 원자 쓰기의 하위 문제, 당신은이 논문에서, 너무, 그 문제에 대해 많은 것을 배울 수 있습니다.) 본 논문은있다 잘못 될 수 있는 것들 에 관한 섹션불완전한 디스크 플러시 는 디스크 에 쓰기가 디스크에 도달하지 못하게 할 수있는 미묘한 복잡성의 예를 제공합니다 (예 : 하드 디스크 컨트롤러가 디스크에 기록하지 않았을 때 디스크에 기록했다고보고하는 경우). ATA 사양에 따라 합법적 일 수도 있습니다.

Unix, Linux 및 Windows를 포함한 대부분의 운영 체제는 쓰기 캐시를 사용하여 작업 속도를 높입니다. 즉, 컴퓨터를 종료하지 않고 끄는 것은 나쁜 생각이며 데이터 손실로 이어질 수 있습니다. USB 저장소를 제거하기 전에 제거 할 경우에도 마찬가지입니다.

대부분의 시스템은 또한 쓰기를 동기식으로 만드는 옵션을 제공합니다. 즉, 응용 프로그램이 성공 확인을 받기 전에 디스크에 데이터가 저장되어 속도가 느려지는 것을 의미합니다.

즉, 컴퓨터를 올바르게 종료하고 제거 할 USB 저장소를 올바르게 준비해야하는 이유가 있습니다.

1. 플래시 기반 스토리지

디스크 유형 (전통적인 하드 드라이브와 솔리드 스테이트 디스크) 또는 내가 알지 못하는 다른 변수에 의존합니까? Linux에서만 발생합니까 (그렇다면) 다른 OS에서도 발생합니까?

선택 사항이 있으면 완전히 종료하지 않고 플래시 기반 스토리지의 전원이 꺼지지 않도록해야합니다.

SD 카드와 같은 저비용 스토리지에서는 전체 지우기 블록 (4KB보다 몇 배 더 큼)이 손실되어 다른 파일이나 파일 시스템의 필수 구조에 속할 수있는 데이터가 손실 될 수 있습니다.

일부 고가의 SSD는 정전시 더 나은 보증을 제공한다고 주장 할 수 있습니다. 그러나 타사 테스트에 따르면 많은 고가의 SSD가 그렇지 않은 것으로 나타났습니다. "마모 레벨링"에 대한 블록을 다시 매핑하는 레이어는 복잡하고 독점적입니다. 가능한 실패는 드라이브의 모든 데이터 손실을 포함합니다.

테스트 프레임 워크를 적용하여 총 3 천 건 이상의 결함 주입주기를 사용하여 6 개의 다른 공급 업체의 17 가지 상용 SSD를 테스트합니다. 우리의 실험 결과는 테스트 된 17 개의 SSD 장치 중 14 개가 비트 손상, 혼돈 쓰기, 직렬화 불가능 쓰기, 메타 데이터 손상 및 전체 장치 고장을 포함하여 전원 오류시 놀라운 고장 동작을 보이는 것으로 나타났습니다.

2017 : https://dl.acm.org/citation.cfm?id=2992782&preflayout=flat

2013 : https://www.usenix.org/system/files/conference/fast13/fast13-final80.pdf?wptouch_preview_theme=enabled

2. 하드 디스크 드라이브 회전

회전하는 HDD의 특성은 다릅니다. 안전과 단순성을 위해 플래시 기반 스토리지와 동일한 실제 불확실성이 있다고 가정합니다.

특정한 증거가 없다면 분명히 그렇지 않습니다. HDD 회전에 대한 비교 수치는 없습니다.

HDD는 불완전하게 작성된 섹터 하나에 잘못된 체크섬이 남게되어 나중에 읽기 오류가 발생할 수 있습니다. 대체로, HDD의이 고장 모드는 전적으로 예상됩니다. 기본 Linux 파일 시스템은이를 염두에두고 설계되었습니다. 그들은 fsync()이러한 유형의 정전 손실에 직면 한 계약을 유지하는 것을 목표로합니다 . (우리는 이것이 SSD에서 보장되는 것을 정말로 원합니다).

그러나 Linux 파일 시스템이 모든 경우에 이것을 달성하는지 또는 가능한지 확실하지 않습니다.

이 유형의 오류 후 다음 부팅시 파일 시스템 복구가 필요할 수 있습니다. 이것은 리눅스이기 때문에 파일 시스템 복구가 이해하지 못하는 몇 가지 질문을 할 수 있습니다. 여기서 Y 키만 누르고 그 자체로 정렬되기를 바랍니다.

2.1 fsync () 계약이 무엇인지 모르는 경우

fsync () 계약은 좋은 소식과 나쁜 소식의 근원입니다. 좋은 소식을 먼저 이해해야합니다.

좋은 소식 : fsync()"저장"을 누른 경우 파일 데이터를 작성하는 올바른 방법으로 문서화되어 있습니다. 예를 들어 텍스트 편집기는 기존 파일을 원자 적으로 대체해야한다는 것이 널리 알려져 rename()있습니다. 이것은 항상 이전 파일을 유지하거나 새 파일 ( fsync()이름 바꾸기 이전 에 ed)을 가져 오도록 하기위한 것입니다. 새 파일의 반으로 작성된 버전을 남기고 싶지 않습니다.

나쁜 소식 : 수년 동안 가장 인기있는 Linux 파일 시스템에서 fsync ()를 호출하면 전체 시스템이 효과적으로 수십 초 동안 중단 될 수 있습니다. 응용 프로그램은 이것에 대해 아무것도 할 수 없으므로 fsync ()없이 rename ()을 낙관적으로 사용하는 것이 일반적이었습니다.이 파일 시스템에서 비교적 안정적인 것으로 보입니다.

따라서 fsync ()를 올바르게 사용하지 않는 응용 프로그램이 있습니다.

이 파일 시스템의 다음 버전은 일반적으로 fsync ()의 올바른 사용에 의존하기 시작하면서 동시에 fsync () 정지를 피했습니다.

이것은 모두 꽤 나쁘다. 이 역사를 이해하는 것은 아마도 충돌하는 많은 커널 개발자들이 사용했던 무시 무시한 분위기와 독창성에 도움이되지 않을 것입니다.

현재 해상도는 현재 가장 인기있는 Linux 파일 시스템입니다. fsync ()를 요구하지 않고 rename () 패턴을 지원하도록 기본 설정이전 버전과의 "버그 간 버그 호환성"을 구현합니다. mount 옵션으로 비활성화 할 수 있습니다 noauto_da_alloc.

이것은 완전한 보호가 아닙니다. 기본적으로 rename () 시간에 보류중인 IO를 플러시하지만 이름을 바꾸기 전에 IO가 완료되기를 기다리지 않습니다. 이것은 60 초 위험 창보다 훨씬 낫습니다! 기존 파일을 rename ()으로 바꿀 때 충돌 안전성을 위해 fsync ()가 필요한 파일 시스템에 대한 답변도 참조하십시오 .

덜 인기있는 파일 시스템은 보호 기능을 제공하지 않습니다. XFS는 거부 합니다. 그리고 UBIFS 는 그것을 구현하지 않았 으며 , 분명히 받아 들일 수는 있지만 가능하게하려면 많은 노력이 필요합니다. 같은 페이지에서 UBIFS에는 전원 손실을 포함하여 데이터 무결성에 대한 몇 가지 다른 "TODO"문제가 있다고 지적합니다. UBIFS는 플래시 스토리지에서 직접 사용되는 파일 시스템입니다. 플래시 스토리지에서 UBIFS가 언급 한 어려움 중 일부는 SSD 버그와 관련이 있다고 생각합니다.

약간로드 된 시스템에서 커널은 write()디스크에 플러시하기 전에 새로 작성된 파일 데이터를 페이지 캐시에 30 초 동안 저장 하여 디스크가 삭제되거나 곧 다시 수정되는 경우를 최적화합니다.

Linux의 dirty_expire_centisecs기본값은 3000 (30 초) 이며 새로 작성된 데이터가 만료되는 시간을 제어합니다. ( https://lwn.net/Articles/322823/ 참조 )

관련 튜너 블에 대한 자세한 내용은 https://www.kernel.org/doc/Documentation/sysctl/vm.txt 를 참조 하십시오 . (예 : google on dirty_writeback_centisecs).

Linux 기본값 /proc/sys/vm/dirty_writeback_centisecs은 500 (5 초) 이며 PowerTop은 1500 (15 초)으로 설정하여 전력 소비를 줄 이도록 권장합니다.

지연된 쓰기 저장은 파일을 디스크에 쓰기 시작하기 전에 커널이 파일의 크기를 알 수있는 시간을 제공합니다. 할당이 지연된 파일 시스템 (예 : XFS 및 요즘 다른 파일 시스템)은 inode 자체에 공간을 할당하는 것과 별도로 필요할 때까지 디스크에서 새로 작성된 파일의 데이터를 넣을 위치를 선택하지 않습니다. 예를 들어, 큰 파일의 시작을 다른 파일 사이의 1 메가 갭에 두지 않도록하여 조각화를 줄입니다.

많은 양의 데이터가 기록되는 경우, 페이지 캐시에 더티 (아직 디스크에 동기화되지 않은) 데이터가 얼마나 많은지에 대한 임계 값에 의해 디스크에 대한 쓰기 저장이 트리거 될 수 있습니다.

그래도 다른 작업을 수행하지 않으면 작은 파일에 저장 한 후 하드 드라이브 작동 표시등이 5 초 또는 15 초 동안 켜지지 않습니다.

fsync()파일을 작성한 후 편집기가 사용 된 경우 커널은 파일을 지연없이 디스크에 씁니다. (그리고 fsync데이터가 실제로 디스크로 전송 될 때까지 반환하지 않습니다).

디스크 내 에서 쓰기 캐싱 도 문제가 될 수 있지만 디스크는 일반적으로 Linux의 페이지 캐시 알고리즘과 달리 쓰기 캐시를 영구 저장소 ASAP에 커밋하려고합니다. 디스크 쓰기 캐시는 작은 쓰기 버스트를 흡수하기위한 저장소 버퍼에 가깝지만 읽기를 위해 쓰기를 지연시키고 디스크에 펌웨어 패턴을 제공하여 탐색 패턴을 최적화 할 수 있습니다 (예 : 하나의 작업 대신 두 개의 근처 쓰기 또는 읽기 수행) 먼 거리를 찾다가 다시 찾고 있습니다.)

회전식 (자기) 디스크에서는 쓰기 전에 읽기 / 쓰기가 보류중인 경우 SATA 쓰기 명령의 데이터가 실제로 전원이 꺼지기 전에 각각 7-10ms의 탐색 지연이 발생할 수 있습니다. (이 질문에 대한 일부 다른 답변은 저널 된 FS가 손상을 피하기 위해 사용할 수있는 디스크 쓰기 캐시 및 쓰기 장벽에 대해 자세히 설명합니다.)