<p>No file systems handle large numbers of files well, putting 600,000+ files in a directory would cause absurd performance problems. Opening and closing that many files during sync would have a performance penalty, versus appending to an already open file and writing its position to an index. Even attempting to delete a folder that large would be a struggle.</p>
<p>A reason the block files are as small as they are is due to limitations in windows file systems that have restrictive legacy compatibility.</p>

CC BY-SA 4.0
2020-11-03T17:44:23.860Z
No, the reason for the block files' small size is so that pruning has reasonable granularity.
Pieter Wuille
CC BY-SA 4.0
2020-11-03T17:44:53.060Z
It predates pruning though.
Claris
CC BY-SA 4.0
2020-11-03T17:45:33.700Z
I'm aware, but I wrote it with pruning in mind.
Pieter Wuille
CC BY-SA 4.0
2020-11-03T16:09:42.760Z
2020-11-03T17:53:04.953Z
2020-11-03T17:53:04.953Z
Claris
<p>Block and reverse patches are currently stored in .dat files, and in each .dat file there are several blocks or reverse patches. What is the reason why blocks are not stored in individual files called, for example, [block_hash].blk and [block_hash].rev and are instead stored in this way?</p>

<implementation>
Why are blocks and reverse patches not stored in individual files?
giacomocaironi
# Why are blocks and reverse patches not stored in individual files?

(Asked by: username_0 on 2020-11-03)

Block and reverse patches are currently stored in .dat files, and in each .dat file there are several blocks or reverse patches. What is the reason why blocks are not stored in individual files called, for example, [block\_hash].blk and [block\_hash].rev and are instead stored in this way?

**Tags:** implementation


---

## 1 answers

### Answer by username_1 on 2020-11-03. Score: 1

No file systems handle large numbers of files well, putting 600,000+ files in a directory would cause absurd performance problems. Opening and closing that many files during sync would have a performance penalty, versus appending to an already open file and writing its position to an index. Even attempting to delete a folder that large would be a struggle.

A reason the block files are as small as they are is due to limitations in windows file systems that have restrictive legacy compatibility.

> **Comments:**
> **username_2**: No, the reason for the block files' small size is so that pruning has reasonable granularity.  
> **username_1**: It predates pruning though.  
> **username_2**: I'm aware, but I wrote it with pruning in mind.  

---

