---
url: https://nsh.dev/hi/docs/layerfs
description: "Native Shell चेकआउट के Linux LayerFS ट्रायल का उपयोग करके Cargo बिल्ड आउटपुट कैप्चर करें, किसी वर्कस्पेस को फ़ोर्क करें और स्नैपशॉट के पुनः उपयोग की जाँच करें।"
---

# LayerFS के साथ लोकल डेवलपमेंट

Native Shell की रिपॉज़िटरी में एक स्थानीय LayerFS वर्कफ़्लो शामिल है, जिससे पुन: उपयोग योग्य बिल्ड वर्कस्पेस का परीक्षण किया जा सकता है। यह कमिट किए गए सोर्स ट्री को इम्पोर्ट करता है, Linux Sandbox के अंदर Cargo चलाता है, परिणामस्वरूप बनी फ़ाइलें सहेजता है और उस सहेजी गई स्थिति के फ़ोर्क से टेस्ट दोबारा चलाता है। सोर्स एडिटिंग और Git कमिट आपके मौजूदा NSH चेकआउट में ही होते हैं।

> [!IMPORTANT]
> इस वर्कफ़्लो के लिए Docker Engine और Linux FUSE आवश्यक हैं। Docker कंट्रोल प्रोसेस और Sandbox चलाता है; FUSE Sandbox के अंदर वर्कस्पेस को माउंट करता है। macOS पर, डेवलपमेंट कमांड OrbStack जैसे स्थानीय Docker इंजन के माध्यम से यह Linux डिप्लॉयमेंट तैयार करता है।

<a id="what-the-snapshot-saves"></a>

## स्नैपशॉट क्या सहेजता है

LayerFS एक फ़ाइलसिस्टम ट्री सहेजता है: सोर्स फ़ाइलें, Git मेटाडेटा, अनदेखी (ignored) फ़ाइलें और वर्कस्पेस के अंदर बने बिल्ड आउटपुट। फ़ोर्क एक सहेजे गए ट्री से शुरू होता है और अपने बदलाव अलग से दर्ज करता है। इससे कई टास्क एक ही बिल्ट स्थिति से शुरू हो सकते हैं, जबकि उनके बदलाव एक-दूसरे से अलग रहते हैं।

NSH के स्थानीय ट्रायल में, पहली ब्रांच `nsh-package` के टेस्ट चलाती है और `target/` तथा एक ignored प्रोब फ़ाइल सहेजती है। दूसरी ब्रांच उस कमिट से शुरू होती है, उन फ़ाइलों की जाँच करती है और टेस्ट ऑफ़लाइन दोबारा चलाती है। तीसरी ब्रांच मूल सोर्स स्थिति से शुरू होती है और आइसोलेशन की पुष्टि करती है।

| Phase | क्या होता है |
| --- | --- |
| Init | चेकआउट के `HEAD` कमिट का एक्सपोर्ट और एक नई `.git` डायरेक्टरी इम्पोर्ट करें |
| Build | एक वर्कस्पेस फ़ोर्क करें और `cargo +1.98.1 test --locked -p nsh-package` चलाएँ |
| Commit | जनरेट हुई `target/` और प्रोब फ़ाइल को LayerFS हिस्ट्री में सहेजें |
| Reuse | सहेजी गई ब्रांच को फ़ोर्क करें, उसे माउंट करें और `--offline` के साथ टेस्ट दोबारा चलाएँ |
| Verify | कमिट हिस्ट्री पढ़ें और जाँचें कि मूल सोर्स ब्रांच साफ़ बनी हुई है |

हर इनवोकेशन एक नया Store बनाता है और यह पूरा क्रम चलाता है। स्नैपशॉट का पुन: उपयोग उसी इनवोकेशन की ब्रांचों के बीच होता है। ट्रायल में मापने योग्य लाभ यह है कि एक और उपयोग योग्य, परीक्षित वर्कस्पेस तक पहुँचने में कितनी लागत लगती है, जिसमें माउंट, कमिट और अनमाउंट का समय भी शामिल है।

<a id="prepare-the-development-environment"></a>

## डेवलपमेंट एनवायरनमेंट तैयार करें

[NSH repository](https://github.com/longbridge/nsh) के एक चेकआउट के साथ निम्नलिखित का उपयोग करें:

- एक स्थानीय Linux Docker इंजन, जिसके Store वॉल्यूम के लिए ext4, XFS या Btrfs हो, और जो Linux पर या OrbStack जैसे macOS एनवायरनमेंट के माध्यम से चल रहा हो।
- 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` पर पिन है। इसकी रनटाइम इमेज Linux प्रोसेस के लिए Rust 1.98.1, Node और clang उपलब्ध कराती है। [upstream SDK guide](https://github.com/Ephemeral-AI-Lab/layerfs/blob/v1.0.0/sdk/js/README.md) Store और Sandbox के लाइफ़साइकल का वर्णन करती है।

ये कमांड NSH चेकआउट के रूट से चलाएँ:

```sh
./scripts/layerfs prepare
./scripts/layerfs smoke
./scripts/layerfs status
```

एक्ज़ीक्यूटेबल Python 3.12 या नया संस्करण चुनता है, जिसमें macOS पर Homebrew की इंस्टॉलेशन भी शामिल है, और सक्रिय Docker कॉन्टेक्स्ट से सॉकेट खोज लेता है। किसी स्थानीय सॉकेट को स्पष्ट रूप से चुनने के लिए `--docker-socket PATH` का उपयोग करें।

`prepare` Docker API की जाँच करता है, Rust 1.85.1 इंस्टॉल करता है और पिन किया गया डेमन, Node addon और रनटाइम इमेज बिल्ड करता है। macOS पर यह इन्हें एक अस्थायी Linux बिल्ड कंटेनर में तैयार करता है। यह सामान्य Cargo रजिस्ट्री और `target/` का पुन: उपयोग करता है, जिसमें मौजूदा `CARGO_TARGET_DIR` सेटिंग भी शामिल है। रनटाइम इमेज का सटीक ID और डेमन का पाथ `.nsh/layerfs/deployment.json` में दर्ज किए जाते हैं। `status` सहेजे गए बिल्ड आउटपुट और इमेज की जाँच करता है और नवीनतम सत्यापन परिणाम दिखाता है।

`smoke` चेकआउट के **कमिट किए गए `HEAD`** से `.nsh/layerfs/nsh-<id>/input` बनाता है, फिर उस इनपुट को एक नए Store में इम्पोर्ट करता है। सोर्स एडिट शामिल करने के लिए, इसे चलाने से पहले उन्हें अपनी टॉपिक ब्रांच में कमिट करें। जनरेट किया गया इनपुट एक नई Git रिपॉज़िटरी से शुरू होता है और अपने बिल्ड आउटपुट Sandbox के अंदर प्राप्त करता है।

कंट्रोल प्रोसेस Store को एक नामित स्थानीय Docker वॉल्यूम में खोलता है। Sandbox डेमन उसी Store को खोलता है और ब्रांच का फ़ाइलसिस्टम व्यू माउंट करता है; Cargo उसी माउंट किए गए वर्कस्पेस में चलता है। सोर्स बदलावों को एडिट और कमिट करने की जगह आपका सामान्य चेकआउट ही रहता है।

<a id="read-the-result"></a>

## परिणाम पढ़ें

कमांड रसीद (receipt) डायरेक्टरी और Store वॉल्यूम का नाम प्रिंट करता है। `"ok": true` और हर phase के बीते समय की जाँच के लिए जनरेट हुई `result.json` खोलें। उसी डायरेक्टरी में `settings.json` होती है, जो सोर्स कमिट और इमेज की पहचान बताती है, और `trace.jsonl`, जो SDK कॉल दर्ज करती है।

स्थानीय सत्यापन में Build और Reuse दोनों phase में 22 पैकेज टेस्ट चले। शुरुआती build/test phase में डिपेंडेंसी डाउनलोड शामिल थे; ऑफ़लाइन phase ने सहेजी गई `target/` और उसी Sandbox की Cargo रजिस्ट्री का उपयोग किया। इसका मूल्य आँकते समय पूरे चक्र की तुलना अपने वर्कलोड पर सामान्य Cargo बिल्ड से करें।

बिल्ट स्थिति का पुन: उपयोग करते समय एक जैसे ऑपरेटिंग सिस्टम, आर्किटेक्चर, टूलचेन और डिपेंडेंसी का उपयोग करें। इस गाइड का वर्कलोड Linux `nsh-package` टेस्ट सूट है; प्लेटफ़ॉर्म UI जाँचें अपने-अपने प्लेटफ़ॉर्म एनवायरनमेंट में चलती हैं ([Testing](https://nsh.dev/translations/hi/docs/testing-and-trace.md))।

<a id="keep-useful-work-and-manage-the-store"></a>

## उपयोगी काम सहेजें और Store को प्रबंधित करें

सोर्स बदलाव Git में रखें और उन्हें pull request के माध्यम से सबमिट करें। ट्रायल दोबारा बनाए जा सकने वाले वर्कस्पेस हिस्ट्री के लिए LayerFS की **Disposable** Store प्रोफ़ाइल का उपयोग करता है। माप दर्ज करते समय उपयोगी रसीदें अलग से सुरक्षित रखें।

जनरेट किया गया इनपुट अपने शुरुआती कमिट के दौरान स्वचालित Git मेंटेनेंस को अक्षम कर देता है, ताकि LayerFS के इम्पोर्ट करते समय ऑब्जेक्ट डेटाबेस स्थिर रहे। ट्रायल के भीतर Git status जाँचें `--no-optional-locks` का उपयोग करती हैं, ताकि status पढ़ने से मूल इंडेक्स सुरक्षित रहे। कस्टम स्क्रिप्ट के लिए, किसी ट्री को इम्पोर्ट या कमिट करने से पहले बैकग्राउंड राइटर पूरे कर लें।

सफलतापूर्वक अनमाउंट किए गए Sandbox LayerFS के idle टाइमआउट के बाद रुक जाते हैं। हर ट्रायल अपना Store वॉल्यूम बनाए रखता है; उस विशेष वॉल्यूम और उसके कंटेनरों को रसीद में दिए गए पहचानकर्ताओं के आधार पर प्रबंधित करें। विफल ऑपरेशन निदान के लिए अपनी दर्ज की गई स्थिति बनाए रखता है। [maintainer reference](https://nsh.dev/translations/docs/dev/layerfs.md) में स्क्रिप्ट, रसीदें और संसाधन क्लीनअप का विवरण है।