# Snap Deals
## Simplified explanation
Snap-deals allow storage providers to accept deals from users and place that user’s data into a block of storage that had already been committed. That was a bit of a mouthful, so picture it like this.
Imagine there is a town with a very long shelf. Anyone in this town can store anything they want on this shelf. When a townsperson wants to store something, they give that *thing* to a storage provider. The storage provider builds a wooden box, puts the townsperson’s stuff into the box, and then puts the box on the shelf.
Sector as a shelf
Some of the boxes have useful stuff in them, like photographs, music, or videos. But sometimes, the storage providers don’t have any townspeople lining up to put useful stuff into the boxes. So instead, they put packing peanuts in the box and put that on the shelf. This means that there are a lot of boxes being made to just hold packing peanuts. Making boxes takes a long time and takes a lot of work from the storage provider.
Data boxes
Instead of creating a new box every time someone wants to store something, it’d be better if we could just replace the packing peanuts with useful stuff! Since nobody cares about the packing peanuts, nobody is going to be unhappy with throwing them out. And the storage provider gets to put useful stuff on the shelf without having to create a new box! Things are better for the townsperson, too, since they don’t have to wait for the storage provider to create a new box!
Replacing data
This is a simplified view of how Snap-deals work. Instead of a storage provider creating an entirely new sector to store a client’s data, they can put the client’s data into a committed capacity sector. The data becomes available faster, things are less expensive for the storage provider, and more of the network’s storage capacity gets utilised!
## How to enable snap-deals
To enable the snap deals pipeline in a Curio cluster, user needs to enable the snap deal specific tasks on the machines that have GPU resources. Apart from this, the deal ingestion pipeline needs to be updated to pass the deals to the snap deal pipeline instead of the PoRep sealing pipeline.
{% hint style="warning" %}
Data can be ingested using either the Snap Deals pipeline or the PoRep pipeline at any given time, but not both simultaneously.
{% endhint %}
## FastSnap (SnapDeals UpdateEncode acceleration)
Curio’s SnapDeals `UpdateEncode` path has a **fast mode** (“fastsnap”) that uses the batch sealing CUDA toolchain (`extern/supraseal`) to accelerate TreeR generation and uses Curio-native snap encoding.
* **Capability check**: run
```bash
curio test supra system-info
```
Look for **“Can run fast TreeR: yes”**.
* **Fallback mode**: if the host lacks AVX-512 (AMD64v4) or a usable CUDA GPU, Curio automatically falls back to a CPU path for TreeR generation.
* **Troubleshooting / force fallback**: set:
```bash
export DISABLE_SUPRA_TREE_R=1
```
This forces the CPU fallback TreeR path (useful to isolate batch sealing/toolchain issues).
### Configuration
{% hint style="warning" %}
When switching between Snap and PoRep deal pipeline, you must ensure that no sectors are being sealed or snapped. All pipelines must be empty before making a switch.
{% endhint %}
#### Curio Market
1. Enable snap deals on base layer. Enabling it on base layer is very important so that no node in the cluster accidentally forwards deal to PoRep pipeline.
2. Save the layer and exit. [Enable snap tasks](#enable-snap-tasks) and restart all the nodes.
```
[Ingest]
DoSnap = true
```
#### Boost Adapter (Deprecated)
{% hint style="warning" %}
Boost adapter is no longer supported with new Curio releases.
{% endhint %}
1. Create or update the market layer ([if one is already created](https://github.com/filecoin-project/curio/blob/main/documentation/en/enabling-market.md#enable-market-adapter-in-curio)) for the minerID where you wish to use snap deals pipeline.
```shell
curio config add --title mt01000
```
\
Add an entry like:
```
[Subsystems]
EnableParkPiece = true
BoostAdapters = ["t10000:127.0.0.1:32100"]
[Ingest]
DoSnap = true
```
\
Press `ctrl + D` to save and exit.\
Or edit the existing layer.
```shell
curio config edit mt01000
```
\
Enable the snap deals for ingestion:
```
[Subsystems]
EnableParkPiece = true
BoostAdapters = ["t10000:127.0.0.1:32100"]
[Ingest]
DoSnap = true
```
\
Save the layer and exit.
2. Add the new market configuration layer to the appropriate nodes based on the [best practices](https://docs.curiostorage.org/best-practices).
### Enable snap tasks
1. Add the `upgrade` layer already shipped with Curio to the `/etc/curio.env` file on the Curio nodes where GPU resources are available.
```
CURIO_LAYERS=gui,seal,post,upgrade <----- Add the "upgrade" layer
CURIO_ALL_REMAINING_FIELDS_ARE_OPTIONAL=true
CURIO_DB_HOST=yugabyte1,yugabyte2,yugabyte3
CURIO_DB_USER=yugabyte
CURIO_DB_PASSWORD=yugabyte
CURIO_DB_PORT=5433
CURIO_DB_NAME=yugabyte
CURIO_REPO_PATH=~/.curio
CURIO_NODE_NAME=ChangeMe
FIL_PROOFS_USE_MULTICORE_SDR=1
```
2. Restart the Curio services on the node.
```
systemctl restart curio
```
***
## Troubleshooting Snap Deals ingestion
### Error: `allocating sector numbers: no suitable sectors found`
Plain-English meaning:
* Curio tried to pick an existing **CC sector** to upgrade (snap), but none matched the constraints.
Common causes:
* There are no CC sectors available to upgrade for that miner.
* Expiration constraints: the candidate sectors cannot satisfy the deal end-epoch requirements.
* Snap pipeline not actually enabled where ingestion runs (layer mismatch).
* Required snap tasks are not running on any GPU-capable node.
What to check first:
1. Confirm ingestion is routed to Snap:
```toml
[Ingest]
DoSnap = true
```
2. Confirm at least one node is running the `upgrade` layer (or equivalent snap task enablement) and has GPU resources.
3. Check in the Curio UI whether the miner has CC sectors expected to be eligible for upgrades.
What to include when asking for help:
* deal UUID + piece CID
* the full error line + surrounding logs
* your `CURIO_LAYERS` for the ingest node and the GPU node
### Error: `skipped scheduling ParkPiece ... out of available Storage`
Plain-English meaning:
* Curio refused to start ParkPiece because there isn’t enough eligible free space on any attached storage path.
What to do:
* Verify free space on the storage paths attached to the node running ParkPiece.
* Check `AllowTypes` / `DenyTypes` in `/sectorstorage.json` (if `unsealed` is effectively disallowed everywhere, ParkPiece can’t place data).
* Check the Curio config knob `ParkPieceMinFreeStoragePercent` (default is 5%) and whether your current free space is below that threshold.
See:
* [Storage Configuration](https://docs.curiostorage.org/storage-configuration)
### Error: `no suitable data URL found for piece_id `
Plain-English meaning:
* Curio has a piece to ingest, but can’t find any usable location for the bytes (most commonly: no data URL was stored for the parked piece).
What to do:
* Ensure you have added a data URL (and any required headers) for the deal/piece.
* Verify the market/ingest layer is enabled on the node that runs ParkPiece.
See:
* [Storage Market](https://docs.curiostorage.org/curio-market/storage-market)
* [Curio Market troubleshooting](https://docs.curiostorage.org/curio-market/troubleshooting)
