내가 추측하는 것은
- EXT4 및 XFS와 같은 파일 시스템. 체크섬과 함께 블록을 디스크(하드 드라이브 또는 SSD일 수 있음)에 씁니다.
- 다시 읽을 때 확인에 실패하면읽다이 작업은 데이터를 반환하지 않으며 오류 또는 EOF(또는 데이터 없음)를 나타냅니다.
- 재부팅 시(운영 체제 메모리 페이지가 플러시되지 않는 갑작스러운 종료 후에도) Linux 운영 체제는 체크섬을 사용하여 파일 블록의 무결성을 확인하고 애플리케이션이 이러한 오류가 감지된 블록을 읽으려고 시도하는 경우 파일의 경우 Linux 운영 체제는 체크섬을 사용하여 파일 블록의 무결성을 확인합니다. 부분의읽다읽기가 위 블록에 도달하면 작업이 실패합니다.
- (Linux 운영 체제에 의해) 감지된 손상된 블록이 파일 중간에 있는 경우. 후속 블록에 오류가 없더라도 손상된 블록에 도달하면 읽기 작업이 실패하며 애플리케이션은 손상된 블록 이후의 데이터를 읽을 수 없습니다.
예를 들어 파일 크기가 4KB이고 블록 크기가 1KB라고 가정합니다. 따라서 이 파일은 A, B, C, D 4개 블록에 걸쳐 배포됩니다. Linux가 블록 C가 손상되었음을 감지했다고 가정합니다. 지금읽다이 작업은 파일의 처음 2KB를 처리할 수 있습니다. 하지만 방법이 없어요읽다애플리케이션이 파일 위치를 3KB 뒤에 배치하더라도 마지막 1KB입니다.
위의 가정이 정확하다면 [파일을 조작하는 일부 침입자는 여기서 고려되지 않습니다.]
- 애플리케이션은 파일을 쓸 때 자체 체크섬을 입력하고 다시 읽을 때 이를 확인할 필요가 없습니다(OS가 갑자기 종료된 후에도).
- 애플리케이션은 제공된 데이터가 다음에서 비롯된 것으로 가정할 수 있습니다.읽다원래 쓰여졌다는 것입니다. 일어날 수 있는 최악의 상황은 파일 끝에서 데이터를 읽을 수 없다는 것입니다.
이러한 가정이 잘못되었습니까(OS=Linux RedHat Enterprise Linux 8.X 및 파일 시스템=EXT4,XFS의 맥락에서)? 그렇다면 무엇이 잘못되었는지 알려주세요..
답변1
EXT4 및 XFS와 같은 파일 시스템. 체크섬과 함께 블록을 디스크(하드 드라이브 또는 SSD일 수 있음)에 씁니다.
아니요, 두 파일 시스템 모두 데이터 체크섬이 없습니다.
다시 읽을 때 체크섬이 실패하면 읽기 작업은 데이터를 반환하지 않으며 오류 또는 EOF(또는 데이터 없음)를 나타냅니다.
아니요. 앞서 언급했듯이 데이터 체크섬은 수행되지 않습니다.예EOF, (틀렸어요!) 없지만 EIO오류 코드가 설정됩니다.
재부팅 시(운영 체제 메모리 페이지가 플러시되지 않는 갑작스러운 종료 후에도) Linux 운영 체제는 체크섬을 사용하여 파일 블록의 무결성을 확인합니다.
아니요. 이는 저널링 파일 시스템이므로 일반적으로 전체 파일 시스템 체크섬 검사가 필요하지 않습니다. 또한 위에서 언급한 것처럼 두 파일 시스템 모두에 데이터 체크섬이 없습니다(적어도 XFS에는 파일 메타데이터에 대한 체크섬이 있습니다).
또한 아니요, 운영 체제로서의 Linux는 존재하는 체크섬, 심지어 데이터 체크섬이 있는 파일 시스템에 대해서도 전체 볼륨 검사를 수행하지 않습니다. 이는 오랜 시간이 걸리며 소프트웨어를 설치하는 일은 사용자에게 맡겨질 가능성이 높습니다. 손상된 체크섬은 저장 장치에 오류가 발생하기 시작했음을 의미할 수 있다는 점을 고려하면 이는 득보다 실이 더 많을 수 있습니다. 앞에서 언급했듯이 최신 파일 시스템에서는 완전한 파일 시스템 검사가 거의 수행되지 않습니다. 대신 액세스 확인이 일반적입니다.
애플리케이션이 이러한 오류 감지 블록이 포함된 파일을 읽으려고 시도하는 경우 읽기가 위 블록에 도달하면 읽기 작업이 실패합니다.
아니요, 데이터 체크섬이 없기 때문입니다. 하지만 그들이 다음과 같다고 가정해보자:
(Linux 운영 체제에 의해) 감지된 손상된 블록이 파일 중간에 있는 경우. 후속 블록에 오류가 없더라도 손상된 블록에 도달하면 읽기 작업이 실패하며 애플리케이션은 손상된 블록 이후의 데이터를 읽을 수 없습니다.
아니요. 나는 Linux와 POSIX가 이에 대해 어떤 보장도 하지 않는다고 생각하며, seek1GB를 초과하면 데이터 체크섬이 있는 파일 시스템에 대한 합리적인 파일 시스템 드라이버는 체크섬을 확인하기 위해 1GB의 데이터를 읽지 않습니다. 따라서 귀하의 가정은 잘못되었습니다.
예를 들어 파일 크기가 4KB이고 블록 크기가 1KB라고 가정합니다. 따라서 이 파일은 A, B, C, D 4개 블록에 걸쳐 배포됩니다.
XFS 작동 방식에 대한 세부 정보는 없으며 일반적으로 ext4 작동 방식에 대한 세부 정보도 없습니다. 범위 기반 할당이 무엇인지 궁금할 것입니다.
Linux가 블록 C가 손상되었음을 감지했다고 가정합니다.
마찬가지로 어떤 파일 시스템이라도가지다데이터 체크섬은 C를 읽을 때만 발생합니다. 늦었 어.
이제 읽기 작업으로 파일의 처음 2KB를 제공할 수 있습니다.
왜 이 이상으로 갈 수 없습니까 fseek?
그러나 응용 프로그램이 파일 위치를 3KB 이후에 배치하더라도 마지막 1KB를 읽을 수 없습니다.
위에서 언급했듯이 이것은 잘못된 것입니다.
하지만,
애플리케이션은 파일을 쓸 때 자체 체크섬을 입력하고 다시 읽을 때 이를 확인할 필요가 없습니다(OS가 갑자기 종료된 후에도).
그렇습니다. 블록 장치 추상화 대신 데이터 무결성을 애플리케이션에 맡기는 것이나쁜설계 오류.
파일 시스템의 핵심은 애플리케이션이 데이터를 저장하는 물리적 매체를 알 필요가 없다는 것입니다. 이러한 추상화를 통해 기본 하드웨어의 추악한 세부 정보가 공개되지 않는다는 것은 애플리케이션이 오류 확률, 발생할 수 있는 오류 유형 및 물리적 미디어에서의 위치를 이해할 수 없다는 것을 의미합니다.
그러나 중복된 정보에 대해 정보를 바탕으로 선택을 하려면 이 모든 것이 필요합니다.
간단히 말해서:파일 시스템을 사용하여 블록 장치에 데이터를 저장할 때 데이터 무결성을 보장하는 것은 애플리케이션 계층이 아닌 블록 장치 계층입니다..
애플리케이션은 읽기에 의해 제공된 데이터가 원래 쓴 데이터라고 가정할 수 있으며, 일어날 수 있는 최악의 상황은 파일 끝에서 데이터를 읽을 수 없다는 것입니다.
적용분야~ 해야 하다파일에서 읽은 데이터가 정확하다고 가정합니다. 그렇지 않으면 응용 프로그램이 정확하거나 수행하는 모든 작업이 정확하다고 가정하지 못합니다. 다시 말하지만 이는 파일 시스템이 애플리케이션에 제공하는 보증입니다. 파일 시스템을 사용하고 있으므로 그렇게 가정할 수 있습니다.
이러한 가정이 잘못되었습니까(OS=Linux RedHat Enterprise Linux 8.X 및 파일 시스템=EXT4,XFS의 맥락에서)? 그렇다면 이 중 어느 것이 잘못된 것인지 알려주세요.
위에서 언급했듯이 기본적으로 모든 가정은 잘못되었습니다.