The Google File System 논문 정리

채택 사유

• HDFS는 구글이 2003년에 발표한 **Google File System (GFS)**을 클론한 것이다. 그래서 이 논문이 얼마나 위대한지! 한번 리뷰해보고 싶었다.
  • HDFS: Hadoop File System은 대용량 데이터를 저장하기 위한 분산 파일시템이다. 거대한 데이터를 여러 컴퓨터에 나누어 저장하는 파일시스템 레이어를 제공하여 데이터의 양이나 시스템의 연산 능력에 선형확장성을 부여한다.

온라인 논문 링크

https://storage.googleapis.com/pub-tools-public-publication-data/pdf/035fc972c796d33122033a0614bc94cff1527999.pdf

정리

Abstract

• 우리는 대규모 분산 데이터 집약적인 애플리케이션을 위한 확장 가능한 분산 파일 시스템인 구글 파일 시스템을 설계하고 구현했습니다.
• 특징
  • 저렴한 범용 하드웨어에서 실행하면서 내결함성(fault tolerance)을 제공하고 다수의 클라이언트에 높은 Aggregate 성능(high aggregate performance)을 제공합니다.
  • 초기 파일 시스템 가정으로부터 현저하게 벗어난 현재 및 예상 애플리케이션 워크로드와 기술 환경을 관찰했고, 전통적인것과 근본적인 디자인을 하게됨.
• 현재까지 가장 큰 클러스터는 1,000대 이상의 머신에서 수천 개의 Disk에 걸쳐 수백 테라바이트의 스토리지를 제공하며, 수백 개의 클라이언트가 동시에 액세스하고 있습니다.
• 본 논문에서, 우리는 분산 애플리케이션을 지원하기 위해 설계된 파일 시스템 인터페이스 확장을 소개하고,설계의 많은 측면과, 실제 상황과 이론상의 벤치마크결과에 대해 이야기하려고 한다.

핵심키워드

Fault tolerance, scalability, data storage, clustered storage

1. Introduction

• 전통적인 분산 파일 시스템과 동일한 목표를 공유

  • 성능, 확장성, 안정성 및 가용성

• 디자인부터 아예 새로운 관점

  1. component failure은 예외가 아니라 일반적인 상황이다. (fail은 예외가 아니라 당연히 생길 수 밖에 없다는 관점) 따라서 지속적인 모니터링, 오류 감지, 내결함성(fault tolerance) 및 자동 복구가 시스템에 필수적이다.
  • 파일의 크기가 커졌다. I/O 작업이나 block 크기 등이 고려되어야 한다.
  • 원래 있는 데이터에 덮어쓰는 작업보다는 새로운 데이터를 추가한다. 따라서 appending이 성능 최적화에 중요해졌다.

2. Design Overview

2.1 assumptions

파일 시스템을 설계할 때의 가정이다.

• 시스템은 잘 고장나는 저렴한 장비들로 구성되어 있다.
• 시스템은 큰 파일(각 파일 크기가 100MB 이상인 수백만 개의 파일이 있을 것으로 예상)이 있다. (작은 파일들도 있지만 optimizing할 때는 고려하지 않는다.)
• workload는 주로 큰 스트리밍 읽기와 작은 랜덤 읽기로 구성되어 있다.
• workload는 또한 파일에 데이터를 추가하는 많은 sequential write가 있다.
• 같은 파일에 여러 사용자가 동시에 데이터를 추가하는 경우도 잘 고려해야 한다.
• 빠른 반응 속도(low latency) 보다는 high sustained bandwidth가 더 중요하다. 대부분의 타겟 애플리케이션은 builk data를 빠른 시간 내에 처리하는 것을 중요하게 여긴다.(bulk 로 잘 처리하는게 더 중요)
  • 개별 읽기 또는 쓰기에 엄격한 응답 시간 요구사항이 있는 애플리케이션은 거의 없다.

2.2 Interface

• 파일은 hierarchically ,디렉토리에 정렬돼있고 path name으로 구분된다.
• 파일을 생성, 삭제, 열기, 닫기, 읽기 및 쓰는 일반적인 작업을 지원한다.
• 또한 GFS는 snapshot과 record append 기능이 있다.(3.3, 3.4 절에서 좀 더 자세히 이야기)
  • snapshot은 파일이나 디렉토리 트리를 복사한다.
  • record append는 각 append의 atomicity를 보장하면서 다수 클라이언트가 데이터를 하나의 파일에 동시에 추가할 수 있도록 해준다.
  • 많은 클라이언트가 추가 잠금 없이 동시에 추가할 수 있는 다방향 병합 결과 및 생산자 소비자 대기열을 구현하는 데 유용하다.

2.3 Architecture

• GFS 클러스터는 하나의 마스터와 여러개의 chunkserver로 구성되어 있다. 그리고 다수의 클라이언트가 접속한다.

  • 다수의 클라이언트: 이들 각각은 일반적으로 사용자 수준 서버 프로세스를 실행하는 일반적인 Linux 시스템이다.
  • 머신 리소스(machine resources)가 허용하고 애플리케이션 코드 실행으로 인한 "신뢰도 저하"를 허용한다면 "청크 서버"와 "클라이언트"를 같은 컴퓨터에서 모두 실행하는 것은 쉽다.
    • 파일 > chunk (key: chunk handle)

• file은 정해진 크기의 chunk로 나누어진다

  • 각 chunk는 청크 생성 시 마스터가 할당한 전역적으로 고유한 64비트 chunk handle로 식별됩니다.
    • chunk server 의 역할
      • 청크 데이터를 읽거나 씁니다.
        • chunk server는 로컬 디스크의 chunk를 Linux 파일로 저장하고 chunk handle 및 바이트 범위에서 지정한 청크 데이터를 읽거나 씁니다.
  • 청크 데이터 복제
    • 각 chunk는 여러 chunk server에 복사된다. 기본값으로는 3 복사.(사용자가 네임스페이스별로 복제 수준 바꿀 수 있음.)
  • master의 역할
    • 마스터는 모든 파일 시스템의 메타데이터를 관리한다.
      • 메타데이터?
        • 네임스페이스, 액세스 제어 정보, 파일에서 chunk로의 매핑 및 chunk의 현재 위치
    • 마스터는 시스템 단위의 활동들을 제어한다
      • chunk lease management(?)
      • garbage collection of orphaned chunks
      • chunk migration between chunkservers
    • 마스터는 각 chunk server와 주기적으로 heartbeat message를 통해 주기적으로 통신해, 명령하고, 상태를 수집한다.
  • 캐싱 관리
    • 클라이언트나 chunk server 둘 다 파일 데이터를 캐싱하지 않는다.대부분 애플리케이션들은 큰 파일을 스트리밍하거나 캐싱되기 너무 큰 작업을 갖기 때문이다.
    • 캐시 일관성 문제를 제거하여 클라이언트와 전체 시스템을 단순화합니다.
      • (그러나 클라이언트는 메타데이터를 캐시합니다.)
    • chunkserver도 파일 데이터를 캐싱할 필요가 없는게 chunk가 로컬 파일로 저장이 되고 리눅스 버퍼캐시가 이미 자주 접근하는 데이터는 메모리에 갖고 있기 때문이다.

2.4 Single Master

• 마스터가 글로벌 지식을 사용하여 정교한 청크 배치 및 복제 결정을 내릴 수 있습니다
• 단일 마스터를 쓰면 단순해지지만 읽기와 쓰기 작업에 관여하는 정도를 최소화해서 병목 현상이 생기지 않도록 해야한다. 클라이언트는 마스터에게 어떤 chunk server를 접속할지를 물어본다. 이 정보를 캐싱해서 많은 연속된 작업을 할 때 청크서버에 직접 접근한다.
  • 그림1 예제. 상단 좌측 맨위 우향 화살표부터 시작
    • 그림 1을 참조하여 간단한 읽기의 상호 작용을 설명하겠습니다.
      • 먼저, 클라이언트는 고정된 청크사이즈를 사용하여 응용 프로그램에서 지정한 파일 이름과 바이트 오프셋을 파일 내의 청크 인덱스로 변환합니다.
      • 그런 다음 파일 이름과 청크 인덱스가 포함된 요청을 마스터에게 보냅니다.
      • 마스터는 해당하는 청크 핸들 및 복제본 위치로 응답합니다. (클라이언트는 파일 이름 및 청크 인덱스를 키로 사용하여 이 정보를 캐시합니다.)
    • 클라이언트는 이 복사본들 중에 가장가까운 것 중 하나에 리퀘스트를 보낸다.(with chunk_handle, byte range) 그 청크를 읽을 때는 캐싱된 정보가 expire되거나 file이 reopen될 때 말고는 마스터와 통신할 일이 없다.
      • 실제로 클라이언트는 일반적으로 동일한 요청에 여러 청크를 요청해 모든걸 한방에 처리해, 클ㄹ라이언트-마스터 상호작용을 회피한다.
      • remind 파일 > chunk (key: chunk handle)

2.5 Chunk Size

청크 사이즈는 디자인 할 때 중요한 요소 중 하나이다. 기본으로 64MB를 설정한다. 각 청크 복사본은 plain Linux file의 모습으로 저장이 된다. lazy space allocation은 internal fragmentation에 의해 생길 수 있는 공간 낭비를 줄여준다.

• 큰 청크 사이즈는 다음과 같은 장점이 있다.
  • 1. 클라이언트가 마스터와 통신하는 일을 줄여준다. 왜냐하면 같은 청크 안에서의 읽기나 쓰기는 마스터에게 다시 요청할 필요가 없기 때문이다. 작은 랜덤 읽기의 경우에도 클라이언트가 청크 위치 정보를 캐싱할 수 있다.
  • 2. 클라이언트가 주어진 청크에서 많은 작업을 할 수 있고 이건 TCP 연결을 계속 유지함으로써 생기는 네트워크 오버헤드를 줄여준다.
  • 3. 마스터가 저장하는 메타데이터의 크기를 줄여준다.
• 반면 단점도 있다. 작은 수의 청크로 구성되어 있다는 것은 이 청크 하나에 많은 클라이언트가 접근하려 할 수 있으므로 hot spot이 될 수 있다. 이런 경우는 더 많은 복사본을 만듦으로써 보완할 수 있다.

2.6 Metadata

• 마스터는 크게 세 가지의 메타데이터를 저장한다.
  • ㄱ. (파일과 청크의)네임스페이스
  • ㄴ. 파일이 청크로 매핑되는 것
  • ㄷ. 각 청크 복사본의 위치이다.
• 모든 메타데이터는 마스터의 메모리에 저장된다.
• 처음 두 데이터(ㄱ,ㄴ)는 변한 내용이 operation log에 로깅된다. 이 로그는 마스터의 로컬 디스크에 있고 remote machine에 복제된다.
• 반면 청크 위치 정보(ㄷ)는 persistently 저장하지 않는다. 대신 청크서버에게 청크 정보를 물어본다. 물어보는 때는 마스터가 시작할 때나 새로운 청크서버가 클러스터에 들어올 때이다.(추정상 해시같은 느낌인듯)

2.6.1 In-Memory Data Structures

• 인메모리로 관리되기 때문에 마스터의 반응이 빠르고 백그라운드에서 전체를 주기적으로 점검하기 효율적이다.
  • 주기 점검
    • 청크 가비지 컬렉션을 구현하고, 청크 서버 장애가 발생할 경우 복제를 다시 수행하고, 청크 마이그레이션하여 청크 서버 간에 로드 및 디스크 공간 사용의 균형을 조정하는 데 사용됩니다.(4.3절~4.3절 에 디테일)
  • 이런 memory-only 접근을 쓸 때 유의할 점은 청크의 갯수, 즉 전체 시스템의 capacity가 마스터가 갖는 메모리에 의해 제한 될 수 있다는 것이다. 하지만 각 64MB 청크마다 마스터는 64bytes 이하를 쓰기 때문에 큰 문제가 되지 않는다.

2.6.2 Chunk Locations

• 마스터는 어떤 청크의 복제본이 어느 청크서버에 있는지에 대해 persistent record를 갖지 않는다. 처음 시작할 때 정보를 받고 그 뒤에 주기적은 heartbeat으로 청크서버를 모니터링한다. Persistently 정보를 갖게 하려고 했지만 그냥 맨 처음에 받고 그 다음에 주기적으로 정보를 받는 게 간단해서 그렇게 구현을 했다. 이렇게 함으로써 청크서버들과 마스터가 동기화돼있게 할 수 있다.

2.6.3 Operation Log

• Operation log는 중요한 메타데이터의 변화를 기록한다. 파일과 청크는 만들어진 logical time에 의해 구분된다. Operation log는 중요하기 때문에 다른 원격 장치에 복사한다. 마스터는 operation log를 통해서 파일 시스템을 복구할 수 있다. 그 시간을 단축시키기 위해서는 로그의 크기를 작게 유지해야한다. 마스터는 로그가 특정 사이즈를 넘으면 체크포인트를 해서 복구할 때 가장 최근의 체크포인트를 로컬 디스크에서 로딩한다. 이 기록은 메모리에 직접 저장할 수 있는 B-tree 형태로 저장되어 추가적인 작업 없이도 네임스페이스 검색에 이용될 수 있다. 복구할 때 가장 최근의 complete한 체크포인트만 필요하고 그 전의 체크포인트는 지워도 되지만 만일에 대비해서 몇 개는 유지한다.

2.7 Consistency Model

• GFS는 고도로 분산된 애플리케이션을 잘 지원하면서도 비교적 단순하고 효율적으로 구현할 수 있는 완화된 일관성 모델을 가지고 있다.

2.7.1 Guarantees by GFS

• 파일 네임스페이스의 변경은 atomic하다. 네임스페이스의 lock 은 정확성과 원자성을 보장한다.(섹션 4.1). 마스터의 operation log가 이런 작업들의 순서를 정의한다. (섹션 2.6.3)

  

• file state after mutation
  • mutation : 변형, write/ recored append. (= 데이터 변화라는 건 write나 record append가 있을 수 있다. )
    • write는 애플리케이션 특정의 파일에 데이터가 쓰여지는 것이다.
    • record append는 concurrent한 변화가 있어도 최소 한 번 atomically append하는 것이다.
  • 데이터 mutation 이후, 파일의 상태는 mutation 유형, 성공여부, 동시성 여부에 따라 달라지고 위의 테이블에 결과가 요약된다.
  • consistent: File region은 모든 클라이언트가 어떤 복제본을 읽든 항상 같은 데이터를 얻는다.
  • defined: 파일 데이터 변화 이후에도 consistent하고 클라이언트가 어떤 쓰기 변화가 있는지 본다
  • 연속으로 성공적인 변화를 하고 나면 변화된 파일 리전은 defined하다고 보장될 수 있고 가장 마지막 변화로 쓰인 데이터를 갖고 있다.
• GFS는 변화를 복제본에 같은 순서로 적용함으로써, 그리고 청크 버전 번호를 이용해서 어떤 복제본이 stale한 지를 찾아냄으로써 위와 같은 보장을 할 수 있다. stale 청크는 클라이언트가 요청해도 제공되지 않고 garbage collected된다. 마스터와 모든 청크서버가 통신하면서 checksumming으로 데이터 결함을 찾아낸다. 문제가 생기면 데이터는 믿을만한 복제본으로부터 복구된다.

2.7.2 Implications for Applications(응용 프로그램 이용)

• (너무 길어져 대충 읽음)
• GFS 애플리케이션은 다른 용도로 이미 필요한 몇 가지 간단한 기술을 사용하여 일관성 완화 모델을 수용할 수 있습니다. 덮어쓰기, 체크포인트, 자체 검증, 자체 식별 레코드 작성보다는 추가 기능에 의존합니다.
  • 추가기능
    • 모든 데이터를 쓴 후 파일 이름을 원자적으로 영구 이름으로 바꾸거나 얼마나 성공적으로 쓰였는지 주기적으로 체크포인트를 한다. 체크포인트는 애플리케이션 수준 체크섬을 포함할 수도 있습니다.
  • 체크포인팅은 작성자가 점진적으로 재시작할 수 있도록 하며, 애플리케이션의 관점에서 아직 불완전한 성공적으로 작성된 파일 데이터를 독자들이 처리하는 것을 막는다.

3. System Interactions(시스템 상호 작용)

• 우리는 모든 작업에 대한 마스터의 개입을 최소화하기 위해 시스템을 설계했습니다.
• 이러한 배경에서 클라이언트, 마스터 및 청크 서버가 상호 작용하여 데이터 mutation, 원자성 레코드 추가 및 스냅샷을 구현하는 방법을 설명합니다.

3.1 Leases and Mutation Order

• mutation은 모든 복제본에서 실행된다.
• 복제본들에서 일정한 mutation 순서를 유지하기 위해 lease를 사용한다.
• 마스터가 primary라고 불리는 하나의 복제본에 청크 리스를 준다.
• primary가 mutation 순서를 고르고, 모든 복제본은 이 순서를 따른다.
• 리스 메커니즘은 마스터의 오버헤드를 줄여주기 위해 만들어졌다. figure2.
  • 1. 어떤 청크서버가 지금 lease를 갖고 있는지 클라이언트가 마스터에게 묻는다. 아무도 없으면 마스터는 하나를 고른다.
  • 2. 마스터는 프라이머리와 다른 복제본의 identity를 알려준다. 클라이언트는 이 데이터를 캐싱한다. 프라이머리가 접근이 안 되거나 더이상 리스를 갖고 있지 않을 때만 다시 마스터와 통신한다.
  • 3. 클라이언트가 모든 복제본에 데이터를 푸쉬한다.
  • 4. 모든 복제본이 데이터를 받게 되면 클라이언트는 쓰기 요청을 프라이머리에게 한다. 프라이머리는 순서대로 뮤테이션을 적용한다. (이게 여러 요청이 왔을 때 그 요청들을 어떤 순서대로 적용할지를 정한다는 건가)
  • 5. 프라이머리는 쓰기 요청을 모든 복제본에게 전달한다. 복제본은 프라이머리가 정한 순서대로 진행한다.
  • 6. 작업이 끝나면 프라이머리에게 끝났다고 알려준다.
  • 7. 프라이머리는 클라이언트에게 완료됐음을 알려준다.
• 

3.2 Data Flow

• 각 머신의 네트워크 대역폭을 최대한 활용하기 위해 데이터는 linearly 푸쉬된다. 트리나 다른 형태가 아니라. 네트워크 병목현상이나 high latency link를 최대한 막기 위해서 각 머신은 데이터를 가장 가까운 머신에게 전달한다. 여러 머신에게 전달 할 때 가까운 머신부터 전달한다. TCP를 통한 데이터 전송을 파이프라이닝 함으로써 지연시간을 줄인다.

3.3 Atomic Record Appends

• 이전의 write는 클라이언트가 데이터가 쓰여질 오프셋을 정했다. 같은 region에 동시에 쓰여지는 것이 serializable하지 않았다. 그 리전은 여러 클라이언트에 의한 데이터 프래그먼트를 가질 것이다. 하지만 record append는 클라이언트는 데이터만 정한다. 그러면 GFS가 그 데이터를 파일에 추가한다. 그러고 그 오프셋을 클라이언트에게 알려준다.

3.4 Snapshot

• 스냅샷은 파일이나 디렉토리 트리의 복사본을 만든다. 마스터가 스냅샷 요청을 받게 되면 먼저 outstanding lease를 revoke한다. 이렇게 하면 어떠한 연속된 쓰기도 lease holder를 찾기 위해 마스터와 교류를 해야 한다. 이렇게 하면 마스터가 새로운 카피를 만들 수 있도록 한다. 리스가 revoke되거나 만료되면 마스터는 디스크에 작업을 로깅한다. 그러고는 이 로그를 인메모리 상태에 기록한다.

4. Master Operation

• 마스터는 모든 네임스페이스 작업을 실행한다. 그리고 청크 복제본을 관리한다.

4.1 Namespace Management and Locking

• 다양한 작업들이 실행될 수 있고 proper serialization을 위해 락을 이용한다. GFS는 per-directory 자료 구조를 갖지 않는다.

4.2 Replica Placement

• Chunk replica placement policy는 두 가지 목적이 있다. data reliability와 availability를 높이는 것과, 네트워크 대역폭 활용을 최대화하는 것이다. 이렇게 하기 위해서는 단순히 머신들에 복제본을 나누는 것이 아니라 rack들에 뿌려야 한다.

4.3 Creation, Re-replication, Rebalancing

• 청크 복제본은 세 가지 이유로 만들어진다. 청크 생성, 재복사, rebalancing.
• 마스터가 청크를 만들 때 처음에 빈 복제본을 어디에 둘 지 정한다.
• 이 때, 고려할 점은
  • 1. 디스크 사용량이 낮은 청크서버에 새 복제본을 둔다.
  • 2. 각 청크서버마다 최근 생성 수를 제한한다.
    3. rack들에 걸쳐서 복제본을 뿌린다.
• 사용 가능한 복제본의 수가 어떤 수 이하로 줄어들면 마스터는 re-replicate한다. 가장 우선 순위가 높은 청크를 골라서 청크서버에게 복사하도록 한다.마스터는 주기적으로 복제본을 rebalancing 한다. 복제본이 어떻게 퍼져있는지를 확인한 뒤 복제본을 더 나은 디스크로 옮겨서 로드밸런싱을 한다.

4.4 Garbage Collection

4.4.1 Mechanism

• 애플리케이션이 파일을 지우면 마스터는 이 로그를 남긴다. 파일은 삭제된 시간이 포함된 hidden name으로 renamed 된다. 마스터가 정기적으로 하는 파일 시스템 네임스페이스 스캔에서 3일 이상 지난 hidden file이 있으면 지운다. 그 전에는 계속 읽힐 수 있고 정상적인 이름으로 바뀜으로써 안 지워질 수 있다. hidden file이 지워지게 되면 인메모리메타데이터가 지워진다. 이와 비슷하게 마스터는 orphaned chunks도 찾는다. 고아 청크는 어떤 파일에게서도 접근이 안 되는 청크이다. 그러고는 메타데이터를 지운다. heartbeat로 각 처ㅇ커서버는 갖고 있는 청크를 보고하고 마스터는 마스터의 메타데이터에 없는 청크를 알려준다. 그러면 청크서버가 지운다.

4.5 Stale Replica Detection

• stale: 일조의 구버전의.

청크서버가 다운되고 그 사이 수정이 일어나게 되면 청크 복제본이 stale될 수 있다. 각 청크마다 마스터는 청크 버전 번호를 갖고 있어서 최신인지 stale인지 알 수 있다. 마스터가 리스를 줄 때 마다 청크 버전 번호를 증가시켜서 최신 복제본임을 알려준다. 마스터는 regular garbage collection 때 stale replica를 제거한다.

5. Fault Tolerance and Diagnosis

• 시스템을 설계하는 데 있어 우리의 가장 큰 과제 중 하나는 빈번한 구성 요소 고장을 처리하는 것이다. 구성 요소의 품질과 양은 이러한 문제를 예외보다 더 일반적인 문제로 만듭니다. 즉, 시스템을 완전히 신뢰할 수도 없고 디스크를 완전히 신뢰할 수도 없습니다. 구성 요소 오류로 인해 시스템을 사용할 수 없거나 데이터가 손상될 수 있습니다. 우리는 이러한 과제를 해결하는 방법과 불가피하게 문제가 발생할 때 진단하기 위해 시스템에 내장된 도구에 대해 논의한다.

5.1 High Availability

• GFS 클러스터에 있는 수백 대의 서버 중 일부는 특정 시간에 사용할 수 없게 되어 있습니다. 우리는 간단하면서도 효과적인 2가지 전략, 즉 빠른 복구 및 복제를 통해 전체 시스템의 가용성을 지속적으로 유지합니다.

5.1.1 Fast Recovory

마스터와 청크서버는 상태를 복구하고 시작하는 데에 몇초만 걸린다.

5.1.2 Chunk Replication

• 청크는 다른 청크서버에 다른 rack에 복제된다.

5.1.3 Master Replication

• 마스터 상태가 복제된다. Operation log와 checkpoints가 다수의 머신에 복제된다.
• shadow master가 primary master가 다운됐을 때 read-only access를 제공할 수 있다. 별로 바뀌지 않는 파일이나 살짝 stale돼도 괜찮다는 애플리케이션에게 제공할 수 있다.
• shadow master도 operation log의 복제본을 읽어서 프라이머리가 하듯 자기의 데이터 구조에 변화를 준다. 프라이머리처럼 시작할 때 청크서버에게 poll하고 그 뒤로는 자주 하지 않지만 청크 복제본과 통신하면서 모니터링한다.

5.2 Data Integrity

• 각 청크서버는 저장된 데이터의 corruption을 탐지하기 위해 checksumming을 사용한다.
• 청크는 32비트 체크섬을 갖고 있다.
• 다른 메타데이터처럼 체크섬도 인메모리에 저장되고 유저 데이터와 별도로 저장된다.
• 읽기 작업이 오면 청크서버는 체크섬을 확인한다. 만약 체크섬에서 오류가 있다면 청크서버는 에러를 반환하고 마스터에게 알려준다.
• 그러면 요청자는 다른 복제본에서 읽을 것이고 마스터는 다른 복제본을 복사할 것이다. 그 뒤에는 mismatch가 일어난 복제본을 지우라고 청크서버에게 지시한다.

6. MEASUREMENTS

• 그래서 얼마나 GFS가 빠르고 효율적인지 측정

  

7. EXPERIENCES

• GFS 만드면서 겪었던 이슈

...

Conclusion

• 전통적인 파일 시스템 관점으로 보지 않고 새로운 시각으로 봤다. component failure을 일반적인 현상으로 봤다. 큰 파일에 대해 최적화를 했다.

---

참고문헌

http://eincs.com/2013/08/why-google-is-great-tech-company/