- 2073 Magh · 10 marks
Large fixed-size chunks in GFS
Short answer
Large fixed 64 MB chunks reduce metadata size and client-master interactions and suit large sequential files. Demerits are hot spots for small popular files, metadata waste for many small files, poor random small accesses, and slower re-replication.
Why do we have large and fixed sized Chunks in GFS? What can be the demerits of that design?
GFS stores each file as fixed-size chunks of 64 MB, much larger than the few-KB blocks of ordinary file systems. Each chunk is a Linux file on a chunkserver, identified by a 64-bit chunk handle.
Why large, fixed-size chunks (advantages)
- Less metadata: fewer chunks mean the master's table is small. One 64 MB chunk needs under 64 bytes of metadata, so all metadata fits in the master's memory, enabling fast operations.
- Fewer client-master interactions: reads and writes on the same chunk need only one request to the master. A client can cache chunk locations for a multi-TB working set.
- Reduced network overhead: a client doing many operations on a chunk can keep a persistent TCP connection to one chunkserver.
- Suits the workload: applications read/write multi-GB files sequentially, so large chunks match the access pattern.
- Simple allocation and lookup: fixed size makes it easy to compute the chunk index from a byte offset (offset / 64 MB), and simplifies replica placement, load balancing and re-replication.
- Lazy space allocation: chunk files are allocated only as needed, so internal fragmentation is avoided.
Demerits
- Hot spots: a small file may consist of one chunk. If many clients access it at the same time (e.g. an executable file being started by hundreds of machines), the chunkservers holding it are overloaded. GFS mitigates this with a higher replication factor and staggered start times.
- Wasted space for small files: a small file still takes a whole chunk entry, and with many small files the master's metadata grows without the benefit of large chunks (lazy allocation limits the disk waste, not the metadata).
- Inefficiency for random access of small data: a whole large chunk must be managed even for small reads.
- Slower re-replication and recovery: copying a 64 MB chunk takes more time and bandwidth than a small block.
- Load imbalance: a few big chunks make it harder to balance load evenly.
- Unsuitable for many small files and for low-latency random workloads.
Summary
Large fixed-size chunks reduce metadata size and master traffic and suit large sequential files, but they cause hot spots for small, popular files and are poor for small-file workloads. GFS reduces the hot-spot problem by higher replication of popular files and by throttling start-up reads.
✓ Answer checked by Claude Opus 5.5 (high effort)
Related questions
- Design wind pressure, large openings, 100 yr · Design of Steel and Timber Structure, chapter 8
- Why do we need DFT · Digital Signal Analysis and Processing, chapter 7 · asked 6×
- T/F: rural design, transformer size first · Transmission and Distribution System Design, chapter 7
- Large vs small scale models; propagation mechanisms · Wireless Communication, chapter 3