You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think, in the 'Welcome' window poped in the first time we run bitcoin-qt, adding an option to config different storage location for blocks data and state data, which allows store them on different type disks (HDD vs. SSD), is really useful.
Description for its usage and advantages
At first, separately store block data and state date has obvious performance improvement, and allows more economic and standing setup.
Storing blocks on big capacity HDD, while storing state on small capacity SSD (or somewhere on SSD), could utilize SSDs' better performance in random I/O (involved in tx validation), and avoid big economic cost of buying an extra big capacity SSD. At the same time, it also relaxes performance requirement towards HDDs (We can use older and cheaper HDDs, or, the same HDD could be on service longer.)
For example:
Currently, I make state directory in my datadir as a symbolic link, to migrate state data to my SSD, successfully making my HDD (a Western Digital Green disk, produced in 2012) reborn to be able to run a full node. Previously, it cannot catch up the chain tip by itself. It just uses extra 10 GB space on my SSD!
I also apply this method for a new full node. The IBD speeds up to cost less than three days (typically cost more than 1 week in HDD-only node at where I live).
Actual benifits in practice
If we can offer an easy way to config it, users will no longer need to bear high economic burden of big capacity SSDs, but still be able to enjoy SSDs' advantage via small capacity SSDs, which is more affordable for new specialized node devices.
Moreover, nowadays, most personal computers use SSDs for the operating system (or even media data). There is enough space on the SSD for state date (but not block data). A relaxing requirement for block-storing disk will decrease their burden for running full node - they have more options in disks, older and cheaper ones are also available.
Add it as an explicit option and tell users what it means (instead of requiring them to learn secure usages of symbolic links), we can help users a lot.
The text was updated successfully, but these errors were encountered:
hebasto
changed the title
A config option to separately stroe blocks and state in start window
A config option to separately store blocks and state in start window
Mar 29, 2024
Feature request for GUI
I think, in the 'Welcome' window poped in the first time we run bitcoin-qt, adding an option to config different storage location for
blocks
data andstate
data, which allows store them on different type disks (HDD vs. SSD), is really useful.Description for its usage and advantages
At first, separately store block data and state date has obvious performance improvement, and allows more economic and standing setup.
Storing blocks on big capacity HDD, while storing state on small capacity SSD (or somewhere on SSD), could utilize SSDs' better performance in random I/O (involved in tx validation), and avoid big economic cost of buying an extra big capacity SSD. At the same time, it also relaxes performance requirement towards HDDs (We can use older and cheaper HDDs, or, the same HDD could be on service longer.)
For example:
state
directory in mydatadir
as a symbolic link, to migrate state data to my SSD, successfully making my HDD (a Western Digital Green disk, produced in 2012) reborn to be able to run a full node. Previously, it cannot catch up the chain tip by itself. It just uses extra 10 GB space on my SSD!Actual benifits in practice
If we can offer an easy way to config it, users will no longer need to bear high economic burden of big capacity SSDs, but still be able to enjoy SSDs' advantage via small capacity SSDs, which is more affordable for new specialized node devices.
Moreover, nowadays, most personal computers use SSDs for the operating system (or even media data). There is enough space on the SSD for state date (but not block data). A relaxing requirement for block-storing disk will decrease their burden for running full node - they have more options in disks, older and cheaper ones are also available.
Add it as an explicit option and tell users what it means (instead of requiring them to learn secure usages of symbolic links), we can help users a lot.
The text was updated successfully, but these errors were encountered: