Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

Remove Unsafe Pruning Flag #8103

Closed
wpank opened this issue Feb 11, 2021 · 9 comments
Closed

Remove Unsafe Pruning Flag #8103

wpank opened this issue Feb 11, 2021 · 9 comments
Assignees
Labels
J0-enhancement An additional feature request.

Comments

@wpank
Copy link

wpank commented Feb 11, 2021

As of now, to run pruned nodes, you must use the flag --unsafe-pruning. Many people are running validators fine with pruning now. This should be removed.

@wi1dcard
Copy link

wi1dcard commented May 2, 2021

Hi @wpank , do you have any update on this issue? Is there an estimated time of removing the flag?

@stale stale bot added the A5-stale Pull request did not receive any updates in a long time. No review needed at this stage. Close it. label Jul 7, 2021
@bLd75
Copy link

bLd75 commented Oct 12, 2021

Hi little bot, the issue is still to be addressed :)

@paradox-tt
Copy link

Seconded.

@bkchr bkchr added J0-enhancement An additional feature request. and removed A5-stale Pull request did not receive any updates in a long time. No review needed at this stage. Close it. labels Jan 17, 2022
@paritytech paritytech deleted a comment from stale bot Jan 19, 2022
@bkchr
Copy link
Member

bkchr commented Jan 26, 2022

We will working on this in the near future.

This issue should be tackled in the following way:

  1. Remove the automatic enabling of "archive mode" when --validator is given.
    pub fn state_pruning(&self, unsafe_pruning: bool, role: &Role) -> error::Result<PruningMode> {
    // by default we disable pruning if the node is an authority (i.e.
    // `ArchiveAll`), otherwise we keep state for the last 256 blocks. if the
    // node is an authority and pruning is enabled explicitly, then we error
    // unless `unsafe_pruning` is set.
    Ok(match &self.pruning {
    Some(ref s) if s == "archive" => PruningMode::ArchiveAll,
    None if role.is_authority() => PruningMode::ArchiveAll,
    None => PruningMode::default(),
    Some(s) => {
    if role.is_authority() && !unsafe_pruning {
    return Err(error::Error::Input(
    "Validators should run with state pruning disabled (i.e. archive). \
    You can ignore this check with `--unsafe-pruning`."
    .to_string(),
    ))
    }
    PruningMode::keep_blocks(s.parse().map_err(|_| {
    error::Error::Input("Invalid pruning mode specified".to_string())
    })?)
    },
    })
    }
  2. Remove --unsafe-pruning cli flag or better make the node fail with an error message that it isn't required anymore:
    /// Force start with unsafe pruning settings.
    ///
    /// When running as a validator it is highly recommended to disable state
    /// pruning (i.e. 'archive') which is the default. The node will refuse to
    /// start as a validator if pruning is enabled unless this option is set.
    #[clap(long)]
    pub unsafe_pruning: bool,
  3. Old nodes should continue to work without requiring to resync or anything. Meaning we should maybe introduce some new PrunningMode::Auto or whatever that ensures that validators that are still running with archive mode continue in archive mode. Any new started validator with a new db should start with a pruned db.
    fn check_meta<D: MetaDb>(mode: &PruningMode, db: &D) -> Result<(), Error<D::Error>> {
    let db_mode = db.get_meta(&to_meta_key(PRUNING_MODE, &())).map_err(Error::Db)?;
    trace!(target: "state-db",
    "DB pruning mode: {:?}",
    db_mode.as_ref().map(|v| std::str::from_utf8(&v))
    );
    match &db_mode {
    Some(v) if v.as_slice() == mode.id() => Ok(()),
    Some(v) => Err(Error::InvalidPruningMode(String::from_utf8_lossy(v).into())),
    None => Ok(()),
    }
    }
    here we check that the pruning modes are matching.

@mmyyrroonn
Copy link

Hi. @RGafiyatullin I have a question here and hope you can shed some light on this. If all validators and watchers in the network are running in the pruned mode, for a new coming node(validator or watcher), is it able to sync the chain from scratch?

@bkchr
Copy link
Member

bkchr commented Mar 22, 2022

Yes, pruning here is only about the state, not the blocks.

@mmyyrroonn
Copy link

Yes, pruning here is only about the state, not the blocks.

oh. Thank you very much! Good to know

RGafiyatullin pushed a commit to RGafiyatullin/cumulus that referenced this issue Apr 8, 2022
@andresilva andresilva moved this to In Progress 🛠 in SDK Node Apr 26, 2022
@RGafiyatullin RGafiyatullin moved this from In Progress 🛠 to Done ✅ in SDK Node May 6, 2022
paritytech-processbot bot pushed a commit to paritytech/cumulus that referenced this issue May 6, 2022
* Substrate API change: paritytech/substrate#8103

* fix fallout of paritytech/polkadot#5454

* update lockfile for {"polkadot"}

Co-authored-by: Bernhard Schuster <[email protected]>
Co-authored-by: parity-processbot <>
@RGafiyatullin
Copy link
Contributor

The --unsafe-pruning emits an obsoletion-warning on the startup now.

This CLI-argument should be completely removed in some future release.

Repository owner moved this from Done ✅ to Blocked ⛔️ in SDK Node May 9, 2022
@RGafiyatullin
Copy link
Contributor

That will remove the CLI-argument completely.

For now it is left as an acceptable CLI-argument in order not to break the existing scripts that may launch the substrate.

@RGafiyatullin RGafiyatullin moved this from Blocked ⛔️ to Done ✅ in SDK Node May 9, 2022
WebWizrd8 added a commit to WebWizrd8/cumulus that referenced this issue Nov 21, 2022
* Substrate API change: paritytech/substrate#8103

* fix fallout of paritytech/polkadot#5454

* update lockfile for {"polkadot"}

Co-authored-by: Bernhard Schuster <[email protected]>
Co-authored-by: parity-processbot <>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
J0-enhancement An additional feature request.
Projects
Status: done
Development

No branches or pull requests

7 participants