Support legacy data directories (#2846)

This commit is contained in:
Paul Hauner 2021-12-02 08:44:38 +11:00
parent ab86b42874
commit 94385fe17b
No known key found for this signature in database
GPG Key ID: 5E2CFF9B75FA63DF
3 changed files with 91 additions and 2 deletions

View File

@ -141,11 +141,47 @@ impl Config {
ensure_dir_exists(self.get_freezer_db_path()) ensure_dir_exists(self.get_freezer_db_path())
} }
/// Returns the "modern" path to the data_dir.
///
/// See `Self::get_data_dir` documentation for more info.
fn get_modern_data_dir(&self) -> PathBuf {
self.data_dir.clone()
}
/// Returns the "legacy" path to the data_dir.
///
/// See `Self::get_data_dir` documentation for more info.
pub fn get_existing_legacy_data_dir(&self) -> Option<PathBuf> {
dirs::home_dir()
.map(|home_dir| home_dir.join(&self.data_dir))
// Return `None` if the directory does not exists.
.filter(|dir| dir.exists())
// Return `None` if the legacy directory is identical to the modern.
.filter(|dir| *dir != self.get_modern_data_dir())
}
/// Returns the core path for the client. /// Returns the core path for the client.
/// ///
/// Will not create any directories. /// Will not create any directories.
pub fn get_data_dir(&self) -> PathBuf { ///
self.data_dir.clone() /// ## Legacy Info
///
/// Legacy versions of Lighthouse did not properly handle relative paths for `--datadir`.
///
/// For backwards compatibility, we still compute the legacy path and check if it exists. If
/// it does exist, we use that directory rather than the modern path.
///
/// For more information, see:
///
/// https://github.com/sigp/lighthouse/pull/2843
fn get_data_dir(&self) -> PathBuf {
let existing_legacy_dir = self.get_existing_legacy_data_dir();
if let Some(legacy_dir) = existing_legacy_dir {
legacy_dir
} else {
self.get_modern_data_dir()
}
} }
/// Returns the core path for the client. /// Returns the core path for the client.

View File

@ -66,6 +66,15 @@ impl<E: EthSpec> ProductionBeaconNode<E> {
let freezer_db_path = client_config.create_freezer_db_path()?; let freezer_db_path = client_config.create_freezer_db_path()?;
let executor = context.executor.clone(); let executor = context.executor.clone();
if let Some(legacy_dir) = client_config.get_existing_legacy_data_dir() {
warn!(
log,
"Legacy datadir location";
"msg" => "this occurs when using relative paths for a datadir location",
"location" => ?legacy_dir,
)
}
if !client_config.chain.enable_lock_timeouts { if !client_config.chain.enable_lock_timeouts {
info!(log, "Disabling lock timeouts globally"); info!(log, "Disabling lock timeouts globally");
TimeoutRwLock::disable_timeouts() TimeoutRwLock::disable_timeouts()

View File

@ -13,3 +13,47 @@ lighthouse --network mainnet --datadir /var/lib/my-custom-dir vc
``` ```
The first step creates a `validators` directory under `/var/lib/my-custom-dir` which contains the imported keys and [`validator_definitions.yml`](./validator-management.md). The first step creates a `validators` directory under `/var/lib/my-custom-dir` which contains the imported keys and [`validator_definitions.yml`](./validator-management.md).
After that, we simply run the beacon chain and validator client with the custom dir path. After that, we simply run the beacon chain and validator client with the custom dir path.
### Relative Paths
[#2682]: https://github.com/sigp/lighthouse/pull/2682
[#2846]: https://github.com/sigp/lighthouse/pull/2846
Prior to the introduction of [#2682][] and [#2846][] (releases v2.0.1 and earlier), Lighthouse would
not correctly parse relative paths from the `lighthouse bn --datadir` flag.
If the user provided a relative path (e.g., `--datadir here` or `--datadir ./here`), the `beacon`
directory would be split across two paths:
1. `~/here` (in the *home directory*), containing:
- `chain_db`
- `freezer_db`
1. `./here` (in the *present working directory*), containing:
- `logs`
- `network`
All versions released after the fix ([#2846][]) will default to storing all files in the present
working directory (i.e. `./here`). New users need not be concerned with the old behaviour.
For existing users which already have a split data directory, a backwards compatibility feature will
be applied. On start-up, if a split directory scenario is detected (i.e. `~/here` exists),
Lighthouse will continue to operate with split directories. In such a scenario, the following
harmless log will show:
```
WARN Legacy datadir location location: "/home/user/datadir/beacon", msg: this occurs when using relative paths for a datadir location
```
In this case, the user could solve this warn by following these steps:
1. Stopping the BN process
1. Consolidating the legacy directory with the new one:
- `mv /home/user/datadir/beacon/* $(pwd)/datadir/beacon`
- Where `$(pwd)` is the present working directory for the Lighthouse binary
1. Removing the legacy directory:
- `rm -r /home/user/datadir/beacon`
1. Restarting the BN process
Although there are no known issues with using backwards compatibility functionality, having split
directories is likely to cause confusion for users. Therefore, we recommend affected users migrate
to a consolidated directory structure.