<p>Bitcoin-Core does serval read and write operations. Blocks can also get deleted in case you have enabled <code>-prune</code>. There are many read operations because your node will very likely serve/relay blocks to other nodes.</p>

<p>The performance of bitcoin-core is more likely constraint by your CPU because of heavy EC verify operations.</p>

CC BY-SA 3.0
2015-08-26T15:36:12.610Z
It's mostly single threaded, Bitcoin Core skips verifying EC signatures in early blocks to avoid taking literally a week to synchronize.
Claris
CC BY-SA 3.0
2015-09-26T01:28:19.927Z
-prune will not reduce I/O operations
Pieter Wuille
CC BY-SA 3.0
2015-08-26T14:27:42.120Z
2015-08-26T14:27:42.120Z
Jonas Schnelli
<p>Linux does not support NTFS very well, any other Linux native file system will be better.</p>

<p>If you are using NTFS with the FUSE driver it will be very slow.</p>

<p>The most common Linux file system is ext4, I'd just use that :)</p>

CC BY-SA 4.0
2022-08-06T17:06:55.553Z
Yes, also NTFS gets corrupted very easily I have experienced.
tread
CC BY-SA 3.0
2015-08-27T00:38:02.823Z
2015-08-27T00:38:02.823Z
JasperWallace
<p>I am running Linux with a harddisk. Currently the blockchain is on an NTFS partition, which probably isn't the fastest. Which filesystem should I choose? As I understand it, a Bitcoin node will only ever append to the blockchain, which means I should not choose a filesystem that is optimized for e.g. fast deletion.</p>

CC BY-SA 3.0
2015-08-21T16:52:00.263Z
I would guess it doesn't matter a lot. After the block chain is downloaded and indexed, there shouldn't be a lot of I/O needed by a Bitcoin node: a random read a few times per second to check the utxo database when verifying incoming transactions, and a few hundred kb of writing every few minutes, when a new block arrives and is indexed. I would start by gathering statistics on the time the client actually spends on I/O, before worrying about which fs is best.
Nate Eldredge
CC BY-SA 3.0
2015-08-21T17:18:24.880Z
well, I am downloading the blockchain now and I have 100 percent disk utilization and still 20 weeks to process. And it seems that each week take a couple of hours on this Pentium 4.
Janus Troelsen
CC BY-SA 3.0
2015-08-21T17:29:47.347Z
How are you measuring disk utilization?  My impression has been that the bottleneck in downloading is more likely to be Internet bandwidth or CPU.  Anyway, the filesystem interaction is not that complicated (reading and writing a relatively small number of large files) so I'd think disk speed is a much greater issue than filesystem.  It's a fair question, but my guess is that even if you use the best possible filesystem (whatever that is), it won't make much difference.
Nate Eldredge
CC BY-SA 3.0
2015-08-22T04:09:45.497Z
FYI: the blockchain is append-only, but blocks can be downloaded out of order and with pruning enabled old blocks may be deleted. This doesn't significantly change your considerations for choosing a filesystem, just FYI.
Jannes
<blockchain><linux><storage>
Fastest filesystem for blockchain?
Janus Troelsen
# Fastest filesystem for blockchain?

(Asked by: username_0 on 2015-08-21)

I am running Linux with a harddisk. Currently the blockchain is on an NTFS partition, which probably isn't the fastest. Which filesystem should I choose? As I understand it, a Bitcoin node will only ever append to the blockchain, which means I should not choose a filesystem that is optimized for e.g. fast deletion.

**Tags:** blockchain, linux, storage

> **Comments:**
> **username_1**: I would guess it doesn't matter a lot. After the block chain is downloaded and indexed, there shouldn't be a lot of I/O needed by a Bitcoin node: a random read a few times per second to check the utxo database when verifying incoming transactions, and a few hundred kb of writing every few minutes, when a new block arrives and is indexed. I would start by gathering statistics on the time the client actually spends on I/O, before worrying about which fs is best.  
> **username_0**: well, I am downloading the blockchain now and I have 100 percent disk utilization and still 20 weeks to process. And it seems that each week take a couple of hours on this Pentium 4.  
> **username_1**: How are you measuring disk utilization?  My impression has been that the bottleneck in downloading is more likely to be Internet bandwidth or CPU.  Anyway, the filesystem interaction is not that complicated (reading and writing a relatively small number of large files) so I'd think disk speed is a much greater issue than filesystem.  It's a fair question, but my guess is that even if you use the best possible filesystem (whatever that is), it won't make much difference.  
> **username_2**: FYI: the blockchain is append-only, but blocks can be downloaded out of order and with pruning enabled old blocks may be deleted. This doesn't significantly change your considerations for choosing a filesystem, just FYI.  

---

## 2 answers

### Answer by username_3 on 2015-08-26. Score: 1 | Accepted answer

Bitcoin-Core does serval read and write operations. Blocks can also get deleted in case you have enabled `-prune`. There are many read operations because your node will very likely serve/relay blocks to other nodes.

The performance of bitcoin-core is more likely constraint by your CPU because of heavy EC verify operations.

> **Comments:**
> **username_4**: It's mostly single threaded, Bitcoin Core skips verifying EC signatures in early blocks to avoid taking literally a week to synchronize.  
> **username_5**: -prune will not reduce I/O operations  

---

### Answer by username_6 on 2015-08-27. Score: 2

Linux does not support NTFS very well, any other Linux native file system will be better.

If you are using NTFS with the FUSE driver it will be very slow.

The most common Linux file system is ext4, I'd just use that :)

> **Comments:**
> **username_7**: Yes, also NTFS gets corrupted very easily I have experienced.  

---

