yorickdowne · January 17, 2025 17:36 · Sep 12, 2023 · Sep 11, 2023 · Sep 11, 2023 · Sep 11, 2023
diff --git a/GethBEHAVE.md b/GethBEHAVE.md
@@ -1,4 +1,4 @@
-> Note: PBSS removes the need to prune manually. It landed in `master` (Docker Hub `latest`) on 8/11/2023, and is scheduled to be part of [Geth 1.13.0](https://github.com/ethereum/go-ethereum/milestone/148).
+> Note: PBSS in Geth >=1.13.0 removes the need to prune manually.
 
 ---
 

diff --git a/GethBEHAVE.md b/GethBEHAVE.md
@@ -1,4 +1,4 @@
-> Note: PBSS removes the need to prune manually. It landed in `master` on 8/11/2023, and is scheduled to be part of [Geth 1.13.0](https://github.com/ethereum/go-ethereum/milestone/148).
+> Note: PBSS removes the need to prune manually. It landed in `master` (Docker Hub `latest`) on 8/11/2023, and is scheduled to be part of [Geth 1.13.0](https://github.com/ethereum/go-ethereum/milestone/148).
 
 ---
 

diff --git a/GethBEHAVE.md b/GethBEHAVE.md
@@ -1,4 +1,4 @@
-> Note: PBSS removes the need to prune entirely. It landed in `master` on 8/11/2023, and is scheduled to be part of [Geth 1.13.0](https://github.com/ethereum/go-ethereum/milestone/148).
+> Note: PBSS removes the need to prune manually. It landed in `master` on 8/11/2023, and is scheduled to be part of [Geth 1.13.0](https://github.com/ethereum/go-ethereum/milestone/148).
 
 ---
 

diff --git a/GethBEHAVE.md b/GethBEHAVE.md
@@ -2,7 +2,7 @@
 
 ---
 
-# **Old content for reference**
+# Old content for reference
 
 # Overview
 

diff --git a/GethBEHAVE.md b/GethBEHAVE.md
@@ -1,10 +1,10 @@
-# Overview
-
 > Note: PBSS removes the need to prune entirely. It landed in `master` on 8/11/2023, and is scheduled to be part of [Geth 1.13.0](https://github.com/ethereum/go-ethereum/milestone/148).
 
 ---
 
-**Old content for reference**
+# **Old content for reference**
+
+# Overview
 
 Geth (Go-Ethereum) as of July 2022 takes about 650 GiB of space on a fast/snap sync, and then grows by [~ 14 GiB/week](https://eth-docker.net/docs/Usage/ResourceUsage/#disk-ram-cpu-requirements) with default cache, ~ 8 GiB/week with more cache.
 

diff --git a/GethBEHAVE.md b/GethBEHAVE.md
@@ -2,6 +2,10 @@
 
 > Note: PBSS removes the need to prune entirely. It landed in `master` on 8/11/2023, and is scheduled to be part of [Geth 1.13.0](https://github.com/ethereum/go-ethereum/milestone/148).
 
+---
+
+**Old content for reference**
+
 Geth (Go-Ethereum) as of July 2022 takes about 650 GiB of space on a fast/snap sync, and then grows by [~ 14 GiB/week](https://eth-docker.net/docs/Usage/ResourceUsage/#disk-ram-cpu-requirements) with default cache, ~ 8 GiB/week with more cache.
 
 This will fill a 2TB SSD in a year or two, to the point where space usage should be brought down again with an offline prune.

diff --git a/GethBEHAVE.md b/GethBEHAVE.md
@@ -11,9 +11,7 @@ Happily, [Geth 1.10.x](https://blog.ethereum.org/2021/03/03/geth-v1-10-0/) intro
 Caveat that while several folx have used offline pruning successfully, there is risk associated with it. The two failure modes
 we have seen already are:
 * There is 37 GiB or less of free disk space
-* The pruning process is interrupted partway through
-
-> Geth is working on a [state storage change](https://twitter.com/peter_szilagyi/status/1539183240799563776) that would drastically reduce its on-disk growth, in a future version of Geth. [Do keep an eye on that](https://github.com/ethereum/go-ethereum/issues/25390).
+* The pruning process is interrupted partway through.
 
 ## Prerequisites
 

diff --git a/GethBEHAVE.md b/GethBEHAVE.md
@@ -1,5 +1,7 @@
 # Overview
 
+> Note: PBSS removes the need to prune entirely. It landed in `master` on 8/11/2023, and is scheduled to be part of [Geth 1.13.0](https://github.com/ethereum/go-ethereum/milestone/148).
+
 Geth (Go-Ethereum) as of July 2022 takes about 650 GiB of space on a fast/snap sync, and then grows by [~ 14 GiB/week](https://eth-docker.net/docs/Usage/ResourceUsage/#disk-ram-cpu-requirements) with default cache, ~ 8 GiB/week with more cache.
 
 This will fill a 2TB SSD in a year or two, to the point where space usage should be brought down again with an offline prune.

diff --git a/GethBEHAVE.md b/GethBEHAVE.md
@@ -2,10 +2,9 @@
 
 Geth (Go-Ethereum) as of July 2022 takes about 650 GiB of space on a fast/snap sync, and then grows by [~ 14 GiB/week](https://eth-docker.net/docs/Usage/ResourceUsage/#disk-ram-cpu-requirements) with default cache, ~ 8 GiB/week with more cache.
 
-This will fill a 1TB SSD in a few months, to the point where space usage should be brought down again with an offline prune.
-> There is an odd behavior with Geth 1.10.20 where initial DB size is large after sync until Geth has been restarted twice. This is expected to be [fixed soon](https://github.com/ethereum/go-ethereum/pull/25379), possibly as soon as 1.10.21.
+This will fill a 2TB SSD in a year or two, to the point where space usage should be brought down again with an offline prune.
 
-Happily, [Geth 1.10.x](https://blog.ethereum.org/2021/03/03/geth-v1-10-0/) introduces "snapshot offline prune", which brings it back down to about its original size. It takes roughly 4-6 hours to prune the Geth database, and this has to be done while Geth is not running.
+Happily, [Geth 1.10.x](https://blog.ethereum.org/2021/03/03/geth-v1-10-0/) introduced "snapshot offline prune", which brings it back down to about its original size. It takes roughly 4-6 hours to prune the Geth database, and this has to be done while Geth is not running.
 
 Caveat that while several folx have used offline pruning successfully, there is risk associated with it. The two failure modes
 we have seen already are:
@@ -18,7 +17,6 @@ we have seen already are:
 
 - [ ] This is not an archive node. Do not try to prune an archive node.
 - [ ] The volume Geth stores its database on has roughly 40 (?) GiB of free space or more. We know 37 GiB is not enough.
-- [ ] Geth 1.10.x installed
 - [ ] Geth is fully synced
 - [ ] Geth has finished creating a snapshot, and this snapshot is 128 blocks old or older, about 35 minutes. You can tell it is done creating the snapshot when it is no longer showing "state snapshot generation" messages in logs. Geth generates a snapshot by default, right after it is done syncing.
 - [ ] `tmux` or similar such as `screen` installed: `sudo apt install tmux`. This [intro](https://medium.com/hackernoon/a-gentle-introduction-to-tmux-8d784c404340) is useful for navigating tmux. tmux just makes sure the prune process continues even when the user is logged out, e.g. because of an idle timer or connection break.

diff --git a/GethBEHAVE.md b/GethBEHAVE.md
@@ -45,7 +45,7 @@ You now have two options, choose whichever is easiest for you.
 ### Systemd option A, use sudo
 
 * First, start `tmux` or `screen`. This is so you can get disconnected and the prune will continue running.
-* Then, with the USER and PATH to `--datadir` from the systemd service file, run `sudo -u USER geth --datadir PATH snapshot prune-state`. If you set up Geth following Somer Esat's guide, that's `sudo -u goeth geth --datadir /var/lib/goethereum snapshot prune-state`. If you followed CoinCashew's instructions to set up Geth, it'd just be `geth snapshot prune-state`.
+* Then, with the USER and PATH to `--datadir` from the systemd service file, run `sudo -u USER geth --datadir PATH snapshot prune-state`. If you set up Geth following Somer Esat's current guide, that's `sudo -u geth geth --datadir /var/lib/geth snapshot prune-state`, or with Somer's original guide it's `sudo -u goeth geth --datadir /var/lib/goethereum snapshot prune-state`. If you followed CoinCashew's instructions to set up Geth, it'd just be `geth snapshot prune-state`.
 
 Note that running as the user Geth usually runs as is critical for the Geth service to still have permissions to its own DB files, when
 you start it up again.

diff --git a/GethBEHAVE.md b/GethBEHAVE.md
@@ -9,15 +9,15 @@ Happily, [Geth 1.10.x](https://blog.ethereum.org/2021/03/03/geth-v1-10-0/) intro
 
 Caveat that while several folx have used offline pruning successfully, there is risk associated with it. The two failure modes
 we have seen already are:
-* There is 25 GiB or less of free disk space
+* There is 37 GiB or less of free disk space
 * The pruning process is interrupted partway through
 
 > Geth is working on a [state storage change](https://twitter.com/peter_szilagyi/status/1539183240799563776) that would drastically reduce its on-disk growth, in a future version of Geth. [Do keep an eye on that](https://github.com/ethereum/go-ethereum/issues/25390).
 
 ## Prerequisites
 
 - [ ] This is not an archive node. Do not try to prune an archive node.
-- [ ] The volume Geth stores its database on has roughly 40 GiB of free space or more. We know 25 GiB is not enough.
+- [ ] The volume Geth stores its database on has roughly 40 (?) GiB of free space or more. We know 37 GiB is not enough.
 - [ ] Geth 1.10.x installed
 - [ ] Geth is fully synced
 - [ ] Geth has finished creating a snapshot, and this snapshot is 128 blocks old or older, about 35 minutes. You can tell it is done creating the snapshot when it is no longer showing "state snapshot generation" messages in logs. Geth generates a snapshot by default, right after it is done syncing.

diff --git a/GethBEHAVE.md b/GethBEHAVE.md
@@ -74,13 +74,14 @@ Once Geth has finished pruning, undo the changes you made:
 ## Pruning if you are using docker-compose to run Geth
 
 If you are using docker-compose, all you need to do is stop the Geth service, and start it again with pruning parameters.
-This has been tested with [eth-docker](https://eth-docker.net/docs/Support/GethPrune).
-> eth-docker supports `./ethd prune-geth` which handles the below steps for you. It also offers an `auto-prune.sh` script
+> [eth-docker](https://eth-docker.net/docs/Support/GethPrune) supports `./ethd prune-geth` which handles the below steps for you. It also offers an `auto-prune.sh` script
 > that can kick off pruning when disk space goes below a threshold, or will just output a warning that crontab can email to you
 > if run as `auto-prune.sh --dry-run`.
 
 > Rocketpool uses `rocketpool service prune-eth1` to prune Geth
 
+Generic docker-compose, this won't work in eth-docker:
+
 * `docker-compose stop execution && docker-compose rm execution`
 * `docker-compose run --rm --name geth_prune -d execution snapshot prune-state`
 * Observe pruning progress with: `docker logs -f --tail 500 geth_prune`

diff --git a/GethBEHAVE.md b/GethBEHAVE.md
@@ -12,7 +12,7 @@ we have seen already are:
 * There is 25 GiB or less of free disk space
 * The pruning process is interrupted partway through
 
-> Geth is working on a [state storage change](https://twitter.com/peter_szilagyi/status/1539183240799563776) that would drastically reduce its on-disk growth, in a future version of Geth. Do keep an eye on that.
+> Geth is working on a [state storage change](https://twitter.com/peter_szilagyi/status/1539183240799563776) that would drastically reduce its on-disk growth, in a future version of Geth. [Do keep an eye on that](https://github.com/ethereum/go-ethereum/issues/25390).
 
 ## Prerequisites
 

diff --git a/GethBEHAVE.md b/GethBEHAVE.md
@@ -38,6 +38,8 @@ and an `ExecStart` in the same file that runs geth, which also specifies the `--
 
 Stop Geth: `sudo systemctl stop geth`
 
+> If Geth does not have enough time to shut down cleanly, the prune may fail. You may need to [give it 180s](https://gist.github.com/yorickdowne/27d4a96174562377d86e4df5d8de654f) to shut down cleanly, depending on your storage hardware
+
 You now have two options, choose whichever is easiest for you.
 
 ### Systemd option A, use sudo

diff --git a/GethBEHAVE.md b/GethBEHAVE.md
@@ -27,7 +27,7 @@ we have seen already are:
 
 Geth will prune in 3 stages: "Iterating state snapshot", "Pruning state data", and "Compacting database". During the "Compacting database" stage, it may not output any log entries for an hour or so ([mainstream SSD](https://gist.github.com/yorickdowne/f3a3e79a573bf35767cd002cc977b038) IOPS). Don't restart it when this happens, let it run!
 
-If you see messages about "generating snapshot" and an ETA during the prune, you don't actually have a snapshot yet! Either the `--datadir` and/or USER aren't right, or Geth just didn't have enough time to complete the snapshot. In that case, do stop the process, run Geth normally again, and observe its logs until snapshot has completed and is 128 blocks old.
+If you see messages about "state snapshot generation" during the prune, you don't actually have a snapshot yet! Either the `--datadir` and/or USER aren't right, or Geth just didn't have enough time to complete the snapshot. In that case, do stop the process, run Geth normally again, and observe its logs until snapshot has completed and is 128 blocks old.
 
 When Geth is done pruning, the process will exit and you will see a log line that contains the phrase `State pruning successful`.
 

diff --git a/GethBEHAVE.md b/GethBEHAVE.md
@@ -20,7 +20,7 @@ we have seen already are:
 - [ ] The volume Geth stores its database on has roughly 40 GiB of free space or more. We know 25 GiB is not enough.
 - [ ] Geth 1.10.x installed
 - [ ] Geth is fully synced
-- [ ] Geth has finished creating a snapshot, and this snapshot is 128 blocks old or older, about 35 minutes. You can tell it is done creating the snapshot when it is no longer showing "generating snapshot" messages in logs. Geth generates a snapshot by default, right after it is done syncing.
+- [ ] Geth has finished creating a snapshot, and this snapshot is 128 blocks old or older, about 35 minutes. You can tell it is done creating the snapshot when it is no longer showing "state snapshot generation" messages in logs. Geth generates a snapshot by default, right after it is done syncing.
 - [ ] `tmux` or similar such as `screen` installed: `sudo apt install tmux`. This [intro](https://medium.com/hackernoon/a-gentle-introduction-to-tmux-8d784c404340) is useful for navigating tmux. tmux just makes sure the prune process continues even when the user is logged out, e.g. because of an idle timer or connection break.
 
 ## What you expect to see

diff --git a/GethBEHAVE.md b/GethBEHAVE.md
@@ -12,7 +12,7 @@ we have seen already are:
 * There is 25 GiB or less of free disk space
 * The pruning process is interrupted partway through
 
-Note: Geth is working on a [state storage change](https://twitter.com/peter_szilagyi/status/1539183240799563776) that would drastically reduce its on-disk growth, in a future version of Geth. Do keep an eye on that.
+> Geth is working on a [state storage change](https://twitter.com/peter_szilagyi/status/1539183240799563776) that would drastically reduce its on-disk growth, in a future version of Geth. Do keep an eye on that.
 
 ## Prerequisites
 

diff --git a/GethBEHAVE.md b/GethBEHAVE.md
@@ -5,7 +5,7 @@ Geth (Go-Ethereum) as of July 2022 takes about 650 GiB of space on a fast/snap s
 This will fill a 1TB SSD in a few months, to the point where space usage should be brought down again with an offline prune.
 > There is an odd behavior with Geth 1.10.20 where initial DB size is large after sync until Geth has been restarted twice. This is expected to be [fixed soon](https://github.com/ethereum/go-ethereum/pull/25379), possibly as soon as 1.10.21.
 
-Happily, [Geth 1.10.x](https://blog.ethereum.org/2021/03/03/geth-v1-10-0/) introduces "snapshot offline prune", which brings it back down to about its original size. It takes roughly 4 hours to prune the Geth database, and this has to be done while Geth is not running.
+Happily, [Geth 1.10.x](https://blog.ethereum.org/2021/03/03/geth-v1-10-0/) introduces "snapshot offline prune", which brings it back down to about its original size. It takes roughly 4-6 hours to prune the Geth database, and this has to be done while Geth is not running.
 
 Caveat that while several folx have used offline pruning successfully, there is risk associated with it. The two failure modes
 we have seen already are:

diff --git a/GethBEHAVE.md b/GethBEHAVE.md
@@ -1,9 +1,9 @@
 # Overview
 
 Geth (Go-Ethereum) as of July 2022 takes about 650 GiB of space on a fast/snap sync, and then grows by [~ 14 GiB/week](https://eth-docker.net/docs/Usage/ResourceUsage/#disk-ram-cpu-requirements) with default cache, ~ 8 GiB/week with more cache.
-> There is an odd behavior with Geth 1.10.20 where initial DB size is large after sync until Geth has been restarted twice. This is expected to be [fixed soon](https://github.com/ethereum/go-ethereum/pull/25379), possibly as soon as 1.10.21.
 
 This will fill a 1TB SSD in a few months, to the point where space usage should be brought down again with an offline prune.
+> There is an odd behavior with Geth 1.10.20 where initial DB size is large after sync until Geth has been restarted twice. This is expected to be [fixed soon](https://github.com/ethereum/go-ethereum/pull/25379), possibly as soon as 1.10.21.
 
 Happily, [Geth 1.10.x](https://blog.ethereum.org/2021/03/03/geth-v1-10-0/) introduces "snapshot offline prune", which brings it back down to about its original size. It takes roughly 4 hours to prune the Geth database, and this has to be done while Geth is not running.
 

diff --git a/GethBEHAVE.md b/GethBEHAVE.md
@@ -1,6 +1,7 @@
 # Overview
 
 Geth (Go-Ethereum) as of July 2022 takes about 650 GiB of space on a fast/snap sync, and then grows by [~ 14 GiB/week](https://eth-docker.net/docs/Usage/ResourceUsage/#disk-ram-cpu-requirements) with default cache, ~ 8 GiB/week with more cache.
+> There is an odd behavior with Geth 1.10.20 where initial DB size is large after sync until Geth has been restarted twice. This is expected to be [fixed soon](https://github.com/ethereum/go-ethereum/pull/25379), possibly as soon as 1.10.21.
 
 This will fill a 1TB SSD in a few months, to the point where space usage should be brought down again with an offline prune.
 

diff --git a/GethBEHAVE.md b/GethBEHAVE.md
@@ -41,7 +41,7 @@ You now have two options, choose whichever is easiest for you.
 
 ### Systemd option A, use sudo
 
-* First, start `tmux`.
+* First, start `tmux` or `screen`. This is so you can get disconnected and the prune will continue running.
 * Then, with the USER and PATH to `--datadir` from the systemd service file, run `sudo -u USER geth --datadir PATH snapshot prune-state`. If you set up Geth following Somer Esat's guide, that's `sudo -u goeth geth --datadir /var/lib/goethereum snapshot prune-state`. If you followed CoinCashew's instructions to set up Geth, it'd just be `geth snapshot prune-state`.
 
 Note that running as the user Geth usually runs as is critical for the Geth service to still have permissions to its own DB files, when
@@ -59,6 +59,8 @@ If you don't want to run tmux, you could modify the Geth service instead.
 * Start the Geth service: `sudo systemctl start geth`
 * You can observe prune progress with `journalctl -fu geth`
 
+**Note**: Unless you also change the restart parameter, systemd will restart the prune after it finishes, which will fail. Once you restore the service to its previous state, you expect Geth to run successfully again.
+
 Once Geth has finished pruning, undo the changes you made:
 
 * Edit the existing file: `sudo nano /etc/systemd/system/geth.service` and remove this from `ExecStart`: `snapshot prune-state`

diff --git a/GethBEHAVE.md b/GethBEHAVE.md
@@ -24,7 +24,7 @@ Note: Geth is working on a [state storage change](https://twitter.com/peter_szil
 
 ## What you expect to see
 
-Geth will prune in 3 stages: "Iterating state snapshot", "Pruning state data", and "Compacting database". During the "Compacting database" stage, it may not output any log entries for an hour or so (mainstream SSD IOPS). Don't restart it when this happens, let it run!
+Geth will prune in 3 stages: "Iterating state snapshot", "Pruning state data", and "Compacting database". During the "Compacting database" stage, it may not output any log entries for an hour or so ([mainstream SSD](https://gist.github.com/yorickdowne/f3a3e79a573bf35767cd002cc977b038) IOPS). Don't restart it when this happens, let it run!
 
 If you see messages about "generating snapshot" and an ETA during the prune, you don't actually have a snapshot yet! Either the `--datadir` and/or USER aren't right, or Geth just didn't have enough time to complete the snapshot. In that case, do stop the process, run Geth normally again, and observe its logs until snapshot has completed and is 128 blocks old.
 

diff --git a/GethBEHAVE.md b/GethBEHAVE.md
@@ -20,8 +20,8 @@ Note: Geth is working on a [state storage change](https://twitter.com/peter_szil
 - [ ] Geth 1.10.x installed
 - [ ] Geth is fully synced
 - [ ] Geth has finished creating a snapshot, and this snapshot is 128 blocks old or older, about 35 minutes. You can tell it is done creating the snapshot when it is no longer showing "generating snapshot" messages in logs. Geth generates a snapshot by default, right after it is done syncing.
-- [ ] `tmux` or similar installed: `sudo apt install tmux`. This [intro](https://medium.com/hackernoon/a-gentle-introduction-to-tmux-8d784c404340) is useful for navigating tmux.
-    
+- [ ] `tmux` or similar such as `screen` installed: `sudo apt install tmux`. This [intro](https://medium.com/hackernoon/a-gentle-introduction-to-tmux-8d784c404340) is useful for navigating tmux. tmux just makes sure the prune process continues even when the user is logged out, e.g. because of an idle timer or connection break.
+
 ## What you expect to see
 
 Geth will prune in 3 stages: "Iterating state snapshot", "Pruning state data", and "Compacting database". During the "Compacting database" stage, it may not output any log entries for an hour or so (mainstream SSD IOPS). Don't restart it when this happens, let it run!

diff --git a/GethBEHAVE.md b/GethBEHAVE.md
@@ -16,7 +16,7 @@ Note: Geth is working on a [state storage change](https://twitter.com/peter_szil
 ## Prerequisites
 
 - [ ] This is not an archive node. Do not try to prune an archive node.
-- [ ] The volume Geth stores its database on has 40 GiB of free space or more. We know 25 GiB is not enough.
+- [ ] The volume Geth stores its database on has roughly 40 GiB of free space or more. We know 25 GiB is not enough.
 - [ ] Geth 1.10.x installed
 - [ ] Geth is fully synced
 - [ ] Geth has finished creating a snapshot, and this snapshot is 128 blocks old or older, about 35 minutes. You can tell it is done creating the snapshot when it is no longer showing "generating snapshot" messages in logs. Geth generates a snapshot by default, right after it is done syncing.

diff --git a/GethBEHAVE.md b/GethBEHAVE.md
@@ -11,6 +11,8 @@ we have seen already are:
 * There is 25 GiB or less of free disk space
 * The pruning process is interrupted partway through
 
+Note: Geth is working on a [state storage change](https://twitter.com/peter_szilagyi/status/1539183240799563776) that would drastically reduce its on-disk growth, in a future version of Geth. Do keep an eye on that.
+
 ## Prerequisites
 
 - [ ] This is not an archive node. Do not try to prune an archive node.

diff --git a/GethBEHAVE.md b/GethBEHAVE.md
@@ -1,6 +1,7 @@
 # Overview
 
-Geth (Go-Ethereum) as of July 2022 takes about 650 GiB of space on a fast/snap sync, and then grows by ~ 10 GiB/week.
+Geth (Go-Ethereum) as of July 2022 takes about 650 GiB of space on a fast/snap sync, and then grows by [~ 14 GiB/week](https://eth-docker.net/docs/Usage/ResourceUsage/#disk-ram-cpu-requirements) with default cache, ~ 8 GiB/week with more cache.
+
 This will fill a 1TB SSD in a few months, to the point where space usage should be brought down again with an offline prune.
 
 Happily, [Geth 1.10.x](https://blog.ethereum.org/2021/03/03/geth-v1-10-0/) introduces "snapshot offline prune", which brings it back down to about its original size. It takes roughly 4 hours to prune the Geth database, and this has to be done while Geth is not running.

diff --git a/GethBEHAVE.md b/GethBEHAVE.md
@@ -1,7 +1,7 @@
 # Overview
 
-Geth (Go-Ethereum) as of July 2022 takes about 830 GiB of space on a fast/snap sync, and then grows by ~ 10 GiB/week.
-This will fill a 1TB SSD in a couple months, to the point where space usage should be brought down again with an offline prune.
+Geth (Go-Ethereum) as of July 2022 takes about 650 GiB of space on a fast/snap sync, and then grows by ~ 10 GiB/week.
+This will fill a 1TB SSD in a few months, to the point where space usage should be brought down again with an offline prune.
 
 Happily, [Geth 1.10.x](https://blog.ethereum.org/2021/03/03/geth-v1-10-0/) introduces "snapshot offline prune", which brings it back down to about its original size. It takes roughly 4 hours to prune the Geth database, and this has to be done while Geth is not running.
 

diff --git a/GethBEHAVE.md b/GethBEHAVE.md
@@ -1,7 +1,7 @@
 # Overview
 
-Geth (Go-Ethereum) as of January 2022 takes about 500 GiB of space on a fast/snap sync, and then grows by ~ 10 GiB/week.
-This will fill a 1TB SSD in ~6 months, to the point where space usage should be brought down again with an offline prune.
+Geth (Go-Ethereum) as of July 2022 takes about 830 GiB of space on a fast/snap sync, and then grows by ~ 10 GiB/week.
+This will fill a 1TB SSD in a couple months, to the point where space usage should be brought down again with an offline prune.
 
 Happily, [Geth 1.10.x](https://blog.ethereum.org/2021/03/03/geth-v1-10-0/) introduces "snapshot offline prune", which brings it back down to about its original size. It takes roughly 4 hours to prune the Geth database, and this has to be done while Geth is not running.
 

diff --git a/GethBEHAVE.md b/GethBEHAVE.md
@@ -25,6 +25,8 @@ Geth will prune in 3 stages: "Iterating state snapshot", "Pruning state data", a
 
 If you see messages about "generating snapshot" and an ETA during the prune, you don't actually have a snapshot yet! Either the `--datadir` and/or USER aren't right, or Geth just didn't have enough time to complete the snapshot. In that case, do stop the process, run Geth normally again, and observe its logs until snapshot has completed and is 128 blocks old.
 
+When Geth is done pruning, the process will exit and you will see a log line that contains the phrase `State pruning successful`.
+
 ## Pruning if you are using systemd to run Geth
 
 systemd will run something like a `geth` service, with a `User` specified in the `/etc/systemd/system/geth.service` file,
No results found