<p>This is an issue of <a href="https://en.wikipedia.org/wiki/Inode" rel="nofollow noreferrer">inodes</a>, a feature mainly in Unix filesystems (like ext4) which is a fixed-size table storing metadata of all files on the partition. When the partition is created, a fixed number of inodes is created.</p>

<p>On my 500GB drive using the default ext4 from Ubuntu, I have 27 million inodes (this can be checked using <code>df -i</code> if you're on Linux), many times more than the number of Bitcoin blocks in the blockchain. Thus I don't run into this issue, and I imagine most people don't - it's possibly something to do with the specific filesystem/setup you're using. </p>

<p>ext4 specifically doesn't have a cap on the number of files in a directory, so splitting the files into multiple directories would be unlikely to help. FAT32  however has a limit of 65,534 files per directory, the solution there is not to use an outdated filesystem like FAT32.</p>

<p>Generally there are two ways to approach this sort of issue:</p>

<ol>
<li>Increase the resource (make more inodes)</li>
</ol>

<p>This can be done by specifying a larger number of inodes when creating the partition, which is relatively easy to do (<a href="https://unix.stackexchange.com/questions/26598/how-can-i-increase-the-number-of-inodes-in-an-ext4-filesystem">example</a>) but requires foresight that you're going to be running a node on the partition. Alternatively, make another partition with the required number of inodes.</p>

<ol start="2">
<li>Use the resource more efficiently (use fewer inodes).</li>
</ol>

<p>Perhaps the simplest way to achieve this is to just stick multiple blocks in a file - I'm not sure how this would work from an architectural point of view but it's something that would have to be implemented in the client.</p>

CC BY-SA 3.0
2018-01-14T15:37:59.863Z
*Perhaps the simplest way to achieve this is to just stick multiple blocks in a file* - which is exactly what Bitcoin Core does.  It just concatenates blocks together until the file size reaches about 128 MB, then starts a new one.  There is a leveldb index to keep track of which block is at which offset in which file.
Nate Eldredge
CC BY-SA 3.0
2018-01-14T13:33:42.863Z
2018-01-14T13:33:42.863Z
mxbi
<p>In this case (which has actually happened to me), if I sync all blocks, they fill up the whole file system table of the volume.</p>

<p>What is the best way to solve it? Using one directory that is split over multiple volumes? How can you achieve that? Using symlinks or junctions?</p>

<p>There is also a limit of files per directory. This means that the entire copy of the blockchain database should be split over a double amount of directories each time it reaches this threshold (like dynamic hashing).</p>

<p>I tried to search for solutions that address these issues, but I simply couldn't find anything, like nobody has ever thought about these situations.</p>

CC BY-SA 3.0
2018-01-14T15:34:04.667Z
Which node software stores every block in a separate file?  Bitcoin Core doesn't do that - it groups them into 128MB chunks, which should make this a non-issue.
Nate Eldredge
CC BY-SA 3.0
2018-01-24T11:27:24.457Z
@Nate Cardano node.
Moon
<blockchain><altcoin><blockchain-data-storage>
What can you do in case the number of blocks becomes greater than the maximal number of files that can be stored in a file system (ext4, FAT, etc.)?
Moon
# What can you do in case the number of blocks becomes greater than the maximal number of files that can be stored in a file system (ext4, FAT, etc.)?

(Asked by: username_0 on 2018-01-14)

In this case (which has actually happened to me), if I sync all blocks, they fill up the whole file system table of the volume.

What is the best way to solve it? Using one directory that is split over multiple volumes? How can you achieve that? Using symlinks or junctions?

There is also a limit of files per directory. This means that the entire copy of the blockchain database should be split over a double amount of directories each time it reaches this threshold (like dynamic hashing).

I tried to search for solutions that address these issues, but I simply couldn't find anything, like nobody has ever thought about these situations.

**Tags:** blockchain, altcoin, blockchain-data-storage

> **Comments:**
> **username_1**: Which node software stores every block in a separate file?  Bitcoin Core doesn't do that - it groups them into 128MB chunks, which should make this a non-issue.  
> **username_0**: @username_1 Cardano node.  

---

## 1 answers

### Answer by username_2 on 2018-01-14. Score: 1 | Accepted answer

This is an issue of [inodes](https://en.wikipedia.org/wiki/Inode), a feature mainly in Unix filesystems (like ext4) which is a fixed-size table storing metadata of all files on the partition. When the partition is created, a fixed number of inodes is created.

On my 500GB drive using the default ext4 from Ubuntu, I have 27 million inodes (this can be checked using `df -i` if you're on Linux), many times more than the number of Bitcoin blocks in the blockchain. Thus I don't run into this issue, and I imagine most people don't - it's possibly something to do with the specific filesystem/setup you're using.

ext4 specifically doesn't have a cap on the number of files in a directory, so splitting the files into multiple directories would be unlikely to help. FAT32 however has a limit of 65,534 files per directory, the solution there is not to use an outdated filesystem like FAT32.

Generally there are two ways to approach this sort of issue:

1. Increase the resource (make more inodes)

This can be done by specifying a larger number of inodes when creating the partition, which is relatively easy to do ([example](https://unix.stackexchange.com/questions/26598/how-can-i-increase-the-number-of-inodes-in-an-ext4-filesystem)) but requires foresight that you're going to be running a node on the partition. Alternatively, make another partition with the required number of inodes.

2. Use the resource more efficiently (use fewer inodes).

Perhaps the simplest way to achieve this is to just stick multiple blocks in a file - I'm not sure how this would work from an architectural point of view but it's something that would have to be implemented in the client.

> **Comments:**
> **username_1**: *Perhaps the simplest way to achieve this is to just stick multiple blocks in a file* - which is exactly what Bitcoin Core does.  It just concatenates blocks together until the file size reaches about 128 MB, then starts a new one.  There is a leveldb index to keep track of which block is at which offset in which file.  

---

