---
url: https://nsh.dev/ru/docs/layerfs
description: "Используйте пробную версию LayerFS для Linux из локальной копии репозитория Native Shell, чтобы сохранять результаты сборки Cargo, создавать форк рабочего пространства и проверять повторное использование снимков."
---
# Локальная разработка с LayerFS
Репозиторий Native Shell включает локальный рабочий процесс LayerFS для тестирования переиспользуемых сборочных рабочих пространств. Он импортирует закоммиченное дерево исходников, запускает Cargo внутри Linux Sandbox, сохраняет полученные файлы и снова запускает тесты из форка этого сохранённого состояния. Редактирование исходников и коммиты Git выполняются в вашем существующем checkout NSH.
> [!IMPORTANT]
> Для этого процесса необходимы Docker Engine и Linux FUSE. Docker запускает управляющий процесс и Sandbox; FUSE монтирует рабочее пространство внутри Sandbox. В macOS команда разработки подготавливает это Linux-окружение через локальный движок Docker, например OrbStack.
## Что сохраняет снимок
LayerFS сохраняет дерево файловой системы: исходные файлы, метаданные Git, игнорируемые файлы и результаты сборки, созданные внутри рабочего пространства. Форк начинается с сохранённого дерева и записывает собственные изменения. Это позволяет нескольким задачам стартовать из одного и того же собранного состояния, сохраняя их изменения раздельными.
В локальной проверке NSH первая ветка запускает тесты `nsh-package` и сохраняет `target/` вместе с игнорируемым пробным файлом. Вторая ветка стартует с этого коммита, проверяет эти файлы и повторяет тесты в офлайн-режиме. Третья ветка стартует с исходного состояния кода и проверяет изоляцию.
| Phase | Что происходит |
| --- | --- |
| Init | Импортируется экспорт коммита `HEAD` из checkout и новый каталог `.git` |
| Build | Создаётся форк рабочего пространства и запускается `cargo +1.98.1 test --locked -p nsh-package` |
| Commit | Сгенерированный `target/` и пробный файл сохраняются в историю LayerFS |
| Reuse | Сохранённая ветка форкается, монтируется, и тесты повторяются с `--offline` |
| Verify | Читается история коммитов и проверяется, что исходная ветка остаётся чистой |
Каждый запуск создаёт новый Store и выполняет эту последовательность целиком. Переиспользование снимка происходит между ветками внутри этого запуска. Измеряемая польза проверки — стоимость получения ещё одного пригодного, протестированного рабочего пространства, включая время монтирования, коммита и размонтирования.
## Подготовка среды разработки
Используйте checkout [репозитория NSH](https://github.com/longbridge/nsh) со следующим:
- Локальный Linux-движок Docker с ext4, XFS или Btrfs для тома Store, работающий в Linux или через окружение macOS, например OrbStack.
- Docker Engine с API версии 1.54 или новее; проверенная локальная конфигурация использует Engine 29.7.2.
- `/dev/fuse`, при этом Docker должен разрешать передачу этого устройства и `CAP_SYS_ADMIN` в Sandbox.
- Git и Python 3.12 или новее; в Linux — также rustup и компилятор C/C++.
- Доступ к сети для загрузки закреплённого исходного кода LayerFS, зависимостей Cargo и образа среды выполнения.
Проверка собирает LayerFS **1.0.0**, закреплённый на исходном коммите `2aaf2552ce21154928b9f9c83582e41a637f5910`. Образ среды выполнения предоставляет Rust 1.98.1, Node и clang для процессов Linux. [Руководство по SDK в upstream](https://github.com/Ephemeral-AI-Lab/layerfs/blob/v1.0.0/sdk/js/README.md) описывает жизненный цикл Store и Sandbox.
Выполняйте эти команды из корня checkout NSH:
```sh
./scripts/layerfs prepare
./scripts/layerfs smoke
./scripts/layerfs status
```
Исполняемый файл выбирает Python 3.12 или новее, включая установку из Homebrew в macOS, и определяет сокет по активному контексту Docker. Используйте `--docker-socket PATH`, чтобы явно выбрать локальный сокет.
`prepare` проверяет API Docker, устанавливает Rust 1.85.1 и собирает закреплённый демон, аддон Node и образ среды выполнения. В macOS это выполняется во временном сборочном контейнере Linux. Команда повторно использует обычный реестр Cargo и `target/`, включая существующую настройку `CARGO_TARGET_DIR`. Точный идентификатор образа среды выполнения и путь к демону записываются в `.nsh/layerfs/deployment.json`. `status` проверяет сохранённые результаты сборки и образ и показывает последний результат валидации.
`smoke` создаёт `.nsh/layerfs/nsh-/input` из **закоммиченного `HEAD`** вашего checkout, затем импортирует этот вход в новый Store. Чтобы включить изменения исходников, закоммитьте их в свою тематическую ветку перед запуском. Сгенерированный вход начинается со свежего репозитория Git и получает результаты сборки внутри Sandbox.
Управляющий процесс открывает Store в именованном локальном томе Docker. Демон Sandbox открывает тот же Store и монтирует представление файловой системы ветки; Cargo выполняется в этом смонтированном рабочем пространстве. Ваш обычный checkout остаётся местом, где вы редактируете и коммитите изменения исходников.
## Чтение результата
Команда выводит каталог квитанций и имя тома Store. Откройте сгенерированный `result.json`, чтобы проверить `"ok": true` и время выполнения каждого этапа. В том же каталоге находятся `settings.json`, который идентифицирует исходный коммит и образ, и `trace.jsonl`, который записывает вызовы SDK.
Локальная валидация выполнила 22 теста пакетов на каждом из этапов build и reuse. Начальный этап сборки и тестирования включал загрузку зависимостей; офлайн-этап использовал сохранённый `target/` и реестр Cargo того же Sandbox. При оценке пользы сравнивайте полный цикл с обычными сборками Cargo на вашей рабочей нагрузке.
Используйте одинаковые операционные системы, архитектуры, наборы инструментов и зависимости при переиспользовании собранного состояния. Рабочая нагрузка этого руководства — набор тестов Linux `nsh-package`; проверки UI платформ используют окружения соответствующих платформ ([Testing](https://nsh.dev/translations/ru/docs/testing-and-trace.md)).
## Сохранение полезной работы и управление Store
Храните изменения исходников в Git и отправляйте их через pull request. Проверка использует профиль Store **Disposable** LayerFS для пересобираемой истории рабочих пространств. Полезные квитанции сохраняйте отдельно, если записываете измерения.
Сгенерированный вход отключает автоматическое обслуживание Git во время начального коммита, сохраняя базу объектов стабильной, пока LayerFS импортирует её. Проверки статуса Git внутри проверки используют `--no-optional-locks`, чтобы чтение статуса сохраняло исходный индекс. В собственных скриптах завершайте фоновые записывающие процессы перед импортом или коммитом дерева.
Успешные размонтированные Sandbox останавливаются после тайм-аута простоя LayerFS. Каждая проверка сохраняет свой том Store; управляйте этим конкретным томом и его контейнерами по идентификаторам из квитанции. Неудачная операция сохраняет записанное состояние для диагностики. [Справочник мейнтейнера](https://nsh.dev/translations/docs/dev/layerfs.md) описывает скрипты, квитанции и очистку ресурсов.