<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://en.bitcoin.it/w/index.php?action=history&amp;feed=atom&amp;title=Splitting_the_data_directory</id>
	<title>Splitting the data directory - Revision history</title>
	<link rel="self" type="application/atom+xml" href="https://en.bitcoin.it/w/index.php?action=history&amp;feed=atom&amp;title=Splitting_the_data_directory"/>
	<link rel="alternate" type="text/html" href="https://en.bitcoin.it/w/index.php?title=Splitting_the_data_directory&amp;action=history"/>
	<updated>2026-04-26T22:58:16Z</updated>
	<subtitle>Revision history for this page on the wiki</subtitle>
	<generator>MediaWiki 1.43.8</generator>
	<entry>
		<id>https://en.bitcoin.it/w/index.php?title=Splitting_the_data_directory&amp;diff=62260&amp;oldid=prev</id>
		<title>Theymos: Created page with &quot;Bitcoin Core normally puts all of its data into one data directory, but oftentimes it is useful to adjust things so that certain of these files go elsewhere.  ==If your da...&quot;</title>
		<link rel="alternate" type="text/html" href="https://en.bitcoin.it/w/index.php?title=Splitting_the_data_directory&amp;diff=62260&amp;oldid=prev"/>
		<updated>2017-02-12T21:31:00Z</updated>

		<summary type="html">&lt;p&gt;Created page with &amp;quot;Bitcoin Core normally puts all of its data into one &lt;a href=&quot;/wiki/Data_directory&quot; title=&quot;Data directory&quot;&gt;data directory&lt;/a&gt;, but oftentimes it is useful to adjust things so that certain of these files go elsewhere.  ==If your da...&amp;quot;&lt;/p&gt;
&lt;p&gt;&lt;b&gt;New page&lt;/b&gt;&lt;/p&gt;&lt;div&gt;Bitcoin Core normally puts all of its data into one [[data directory]], but oftentimes it is useful to adjust things so that certain of these files go elsewhere.&lt;br /&gt;
&lt;br /&gt;
==If your data directory is on a magnetic disk: Moving chainstate for improved speed==&lt;br /&gt;
&lt;br /&gt;
Bitcoin Core&amp;#039;s overall speed is significantly affected by the random-access speed of the contents of the chainstate directory; if your data directory is located on a magnetic disk, your chainstate access speed will very probably be the biggest performance bottleneck. You can therefore often massively improve performance by moving just the chainstate directory (which is only a few GB) to an SSD drive. Even moving the chainstate directory to a USB flash drive can often provide a large performance improvement, especially if the USB flash drive is advertised as being particularly high-speed.&lt;br /&gt;
&lt;br /&gt;
To move it:&lt;br /&gt;
&lt;br /&gt;
# Shut down Bitcoin Core&lt;br /&gt;
# From the [[data directory]], &amp;#039;&amp;#039;cut&amp;#039;&amp;#039; the chainstate directory (not just its contents, but the directory itself) and &amp;#039;&amp;#039;paste&amp;#039;&amp;#039; it somewhere on the target drive. On Linux, make sure that permissions allow for Bitcoin Core to read/write the directory and its files at the new location.&lt;br /&gt;
# Open a terminal in the data directory. (On Windows, Shift-RightClick the [[data directory]] and choose &amp;quot;open a command window here&amp;quot;.) On Linux, run &amp;lt;tt&amp;gt;ln -s /absolute/path/to/chainstate&amp;lt;/tt&amp;gt;. For example, if you moved your chainstate so that its new location is /mnt/ssd/core/chainstate (ie. within that directory are a bunch of ldb files), you&amp;#039;d run &amp;lt;tt&amp;gt;ln -s /mnt/ssd/core/chainstate&amp;lt;/tt&amp;gt; from immediately within the data directory. On Windows, run &amp;lt;tt&amp;gt;mklink /D chainstate ?:\path\to\chainstate&amp;lt;/tt&amp;gt;. For example, if you moved your chainstate so that its new location is F:\core\chainstate (ie. within that directory are a bunch of ldb files), you&amp;#039;d run &amp;lt;tt&amp;gt;mklink /D chainstate F:\core\chainstate&amp;lt;/tt&amp;gt; from immediately within the data directory.&lt;br /&gt;
&lt;br /&gt;
If you&amp;#039;re using a removable drive, make sure that the path to the real chainstate does not change.&lt;br /&gt;
&lt;br /&gt;
==If your data directory is on an SSD: Moving the blocks database to save space==&lt;br /&gt;
&lt;br /&gt;
Unlike the chainstate directory mentioned in the previous section, the blk* and rev* files in the blocks directory in the [[data directory]] are rarely accessed, and when accessed they are accessed in a highly sequential access pattern, so it will not affect performance much at all to move them to a magnetic disk, thereby freeing up 100+ GB on your SSD.&lt;br /&gt;
&lt;br /&gt;
Note that you can avoid the need to store the blocks database at all by running Bitcoin Core with pruning enabled (ie. add &amp;lt;tt&amp;gt;prune=550&amp;lt;/tt&amp;gt; to bitcoin.conf), but then you will lose some features and be slightly less helpful to the network. Security is not affected by this, however, and you remain a [[full node]].&lt;br /&gt;
&lt;br /&gt;
Unlike in the chainstate case, you don&amp;#039;t want to move the entire blocks directory because this would move the performance-relevant &amp;lt;tt&amp;gt;blocks/index&amp;lt;/tt&amp;gt; directory as well. Instead, you can place the following script in the blocks directory and run it periodically &amp;#039;&amp;#039;&amp;#039;with Bitcoin Core shut down&amp;#039;&amp;#039;&amp;#039; to move the blk* and rev* files individually. Do not run the script while Bitcoin Core is running or you will probably wreck things in such a way that you will have to sync from 0. Modify BLK_TARGET=... in the script to point to your desired target location.&lt;br /&gt;
&lt;br /&gt;
Linux:&lt;br /&gt;
&amp;lt;pre&amp;gt;#!/bin/bash&lt;br /&gt;
set -e&lt;br /&gt;
BLK_TARGET=/mnt/ssd/core/blocks #Replace with your destination, no trailing slash&lt;br /&gt;
&lt;br /&gt;
find . -name &amp;#039;*.dat&amp;#039; -type f -printf &amp;#039;%f\n&amp;#039; &amp;gt; tomove&lt;br /&gt;
while read line; do&lt;br /&gt;
        echo $line&lt;br /&gt;
        mv &amp;quot;$line&amp;quot; &amp;quot;$BLK_TARGET/$line&amp;quot;&lt;br /&gt;
        ln -s &amp;quot;$BLK_TARGET/$line&amp;quot; &amp;quot;$line&amp;quot;&lt;br /&gt;
done &amp;lt;tomove&lt;br /&gt;
rm tomove&lt;br /&gt;
echo Done&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Windows (save as &amp;lt;tt&amp;gt;move.bat&amp;lt;/tt&amp;gt; or something):&lt;br /&gt;
&amp;lt;pre&amp;gt;@echo off&lt;br /&gt;
REM Change the following line to your destination, no trailing slash&lt;br /&gt;
SET BLK_TARGET=F:\core\blocks&lt;br /&gt;
for /f %%f in (&amp;#039;dir /A-L /b *.dat&amp;#039;) do (&lt;br /&gt;
	move %%f %BLK_TARGET%\%%f&lt;br /&gt;
	if exist %%f (&lt;br /&gt;
		echo Something went wrong&lt;br /&gt;
		pause&lt;br /&gt;
		exit&lt;br /&gt;
	)&lt;br /&gt;
	mklink %%f %BLK_TARGET%\%%f&lt;br /&gt;
)&lt;br /&gt;
echo Done&lt;br /&gt;
pause&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
These scripts expect to be inside of the &amp;lt;tt&amp;gt;blocks&amp;lt;/tt&amp;gt; directory in the [[data directory]], next to the blk and rev files. They do only minimal error handling -- use with care.&lt;br /&gt;
&lt;br /&gt;
To undo the script, just move all of the files back to where they were originally, overwriting the symlinks.&lt;br /&gt;
&lt;br /&gt;
[[Category:Guides]]&lt;/div&gt;</summary>
		<author><name>Theymos</name></author>
	</entry>
</feed>