LogoLogo
v2.x (Stable)
v2.x (Stable)
  • What is Boost?
  • Features
  • Components
    • boostd
      • Repository
      • GraphQL API
      • JSON-RPC API
      • SQLite metadata database
    • Local Index Directory
      • Index types
      • Dependencies
      • Initialisation
    • boostd-data
    • YugabyteDB
    • booster-http
    • booster-bitswap
    • libp2p Protocols
  • Hardware requirements
    • YugabyteDB
  • Installation
  • New Boost Setup
  • Configuration
    • UI Settings
    • HTTP Transfer limit
    • Deal Filters
    • Remote CommP
    • Legacy Deal configuration
    • HTTP indexer announcement
    • Manual Publish Storage Deal Message
  • Monitoring
    • Setting up a monitoring stack for Boost
  • Storing data on Filecoin
  • Retrieving data from Filecoin
    • HTTP retrieval
    • Advanced Configuration of booster-http
    • Bitswap retrieval
  • Backup and Restore
  • Tutorials
    • How to upgrade from Boost v1 to Boost v2
    • How to re-index unsealed pieces that are flagged by LID in Boost v2
    • How to upgrade from v2.0.0 to v2.1.0
    • How to upgrade from v2.1.x to v2.2.0
    • Start and stop Boost processes
    • How to store files with Boost on Filecoin
    • Using filters for storage and retrieval deals
    • Migrate from Lotus to Boost
    • How to onboard data using DDO deals
  • Troubleshooting
  • Experimental Features
    • FVM Contract Deals
    • Direct Deals
    • Data Segment Indexing
  • FAQ
  • Need help?
Powered by GitBook
On this page
Edit on GitHub
Export as PDF
  1. Components
  2. Local Index Directory

Initialisation

This page explains how to initialise LID and start using it to provide retrievals to clients

PreviousDependenciesNextboostd-data

Last updated 1 year ago

Considering that the Local Index Directory is a new feature, Storage Providers should initialise it after upgrading their Boost deployments.

There are two ways a Storage Provider can do that:

  1. Migrate existing indices from the DAG store into LID: this solution assumes that the Storage Provider has been keeping an unsealed copy for every sector they prove on-chain, and has already indexed all their deal data into the DAG store. Typically index sizes for a given sector range between 100KiB up to 1GiB, depending on deal data and its blocks sizes. The DAG store keeps these indices in the repository directory of Boost under the ./dagstore/index and ./dagstore/datastore directories. This data should be migrated to LID with the migrate-lid utility.

  2. Recreate indices for deal data based on unsealed copies of sectors: this solution assumes that the Storage Provider has unsealed copies for every sector they prove on-chain. If this is not the case, then the SP should first trigger an unseal (UNS) job on their system for every sector that contains user data and produce an unseal copy. SPs can use the boostd recover lid utility to produce an index for all deal data within an unsealed sector and store it in LID so that they enable retrievals for the data. Depending on SPs deployment and where unsealed copies are hosted (NFS, Ceph, external disks, etc.) and the performance of the hosting system, producing an index for a 32GiB sector can take anywhere from a few seconds up to a few minutes, as the unsealed copy needs to be processed by the utility.

If you are migrating from Boost v1, make sure to read the tutorial:

How to upgrade from Boost v1 to Boost v2