NVMe TCP के ज़रिए लैपटॉप क्लोन करना

 (copyninja.in)
2 पॉइंट द्वारा GN⁺ 2024-03-13 | 1 टिप्पणियां | WhatsApp पर शेयर करें

NVMe TCP का उपयोग करके लैपटॉप क्लोन करना

  • हाल ही में एक नया लैपटॉप खरीदा और उसे इस्तेमाल के लिए सेटअप करना था।
  • पहले से ज्ञात चरणों को फिर से दोहराने का कोई उत्साह नहीं था।
  • एक सहकर्मी के सुझाव पर, पुराने डिस्क को नए लैपटॉप में कॉपी करने के तरीके पर विचार किया।

क्लोनिंग प्रक्रिया को लेकर सवाल

  • पुराने लैपटॉप को खोलकर नए डिस्क को USB से जोड़ने के लिए कोई टूल नहीं था।
  • Full-disk encryption का उपयोग किया जा रहा था, और पुराने लैपटॉप में 512GB जबकि नए लैपटॉप में 1TB NVME था।
  • LUKS partition का आकार बदलने का अनुभव नहीं था।

सहकर्मी का सुझाव

  • NVME over TCP का उपयोग करके डिस्क को नेटवर्क के ज़रिए share करने और पूरी डिस्क की कॉपी करने का सुझाव दिया गया।
  • सुझाए गए चरण इस प्रकार थे:
    • पुराने लैपटॉप पर nvmet-tcp का उपयोग करके डिस्क export करना।
    • नए लैपटॉप पर डिस्क कॉपी करना।
    • partition का आकार बदलकर पूरे 1TB का उपयोग करना।
    • LUKS का आकार बदलना।
    • अंत में BTRFS root disk का आकार बदलना।

NVME TCP के ज़रिए डिस्क export करना

  • systemd-storagetm.service का उपयोग सबसे आसान तरीका बताया गया।
  • इसके बजाय, दोनों लैपटॉप को GRML rescue CD से boot किया गया और nvmet-tcp module का उपयोग करके NVME डिस्क export करने के चरण पूरे किए गए।

डिस्क कॉपी

  • dd command का उपयोग करके root disk को नए लैपटॉप में कॉपी किया गया।
  • नए लैपटॉप में Ethernet port नहीं था, इसलिए केवल Wi-Fi का उपयोग करना पड़ा, और पूरे 512GB को कॉपी करने में लगभग 7 घंटे 30 मिनट लगे।
  • कॉपी की गति लगभग 18-20MB/s थी।

partition और LUKS container का आकार बदलना

  • parted चलाने पर उसने पाया कि partition table डिस्क के आकार से मेल नहीं खा रही थी और उसे ठीक करने के लिए कहा।
  • cloud-guest-utils install करके growpart का उपयोग किया गया ताकि partition को 1TB तक बढ़ाया जा सके।
  • cryptsetup-resize का उपयोग करके LUKS container का आकार बढ़ाया गया।
  • सिस्टम में login करने के बाद BTRFS file system का आकार बदला गया।

निष्कर्ष

  • इस प्रक्रिया का एकमात्र लाभ यह था कि नया लैपटॉप इस्तेमाल करते हुए भी वही अनुभव मिलता है जैसा पुराने लैपटॉप का था।
  • आम तौर पर नए लैपटॉप को सेटअप करने में 1-2 हफ्ते लगते हैं, लेकिन इस मामले में वह समय बच गया।
  • एक अतिरिक्त लाभ यह भी रहा कि NVME over TCP का उपयोग करके डिस्क export करना सीखा।

GN⁺ की राय

  • NVME over TCP के ज़रिए लैपटॉप क्लोन करना मौजूदा सिस्टम environment को नए hardware पर तेज़ी से स्थानांतरित करने का एक प्रभावी तरीका दिखाता है।
  • यह तकनीक system administrator और developers के लिए समय बचाने और setup errors को कम करने के उपाय के रूप में दिलचस्प हो सकती है।
  • हालांकि, यह network speed पर बहुत अधिक निर्भर करती है, और अगर केवल Wi-Fi उपलब्ध हो तो इसमें काफ़ी समय लग सकता है, जो एक ध्यान देने योग्य कमी है।
  • Clonezilla या Acronis जैसे टूल समान क्षमताएँ देते हैं, लेकिन NVME over TCP का खास फ़ायदा नेटवर्क के ज़रिए सीधा disk access है।
  • इस तकनीक को अपनाते समय network configuration, encrypted disks को संभालना, और file system resizing जैसी चीज़ों की पर्याप्त समझ होना ज़रूरी है।

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-03-13
Hacker News राय

  • लेखक के परिदृश्य में NVMe/TCP इस्तेमाल करने का कोई फ़ायदा नहीं है। क्योंकि वह बस dd का उपयोग करके serial block copy कर रहा है, इसलिए concurrent I/O का लाभ नहीं मिल पाता। जटिल commands को सरल netcat से बदला जा सकता है.

    • destination laptop पर $ nc -l -p 1234 | dd of=/dev/nvme0nX bs=1M इस्तेमाल करें.
    • source laptop पर $ nc x.x.x.x 1234 </dev/nvme0nX इस्तेमाल करें.
    • destination पर dd write operation को buffer करता है, जिससे यह तेज़ और अधिक efficient बनता है। source/destination पर gzip/gunzip जोड़ने से, अगर disk पूरी भरी न हो, तो पूरा काम काफ़ी तेज़ हो जाता है। network के ज़रिए PC image बनाने का यह मेरा पसंदीदा तरीका है। gzip को --fast option देना, या इसे तेज़ lz4/unlz4 से बदलना अच्छा है। हाल ही में 1TB NVMe वाले एक नए Windows laptop की imaging करते समय इसका उपयोग किया था; GigE पर इसमें लगभग 20 मिनट लगे और result image 20GB की थी। आम तौर पर मैं इस lz4 image को backup रखता हूँ और कुछ साल बाद laptop दान करते समय unlz4 | dd से restore करता हूँ। यह बहुत सुविधाजनक है.
    • Linux kernel module nvme-tcp के बारे में नहीं जानता था, लेकिन हर दिन कुछ नया सीखता हूँ। इस module की उपयोगिता dd से raw access करने से ज़्यादा remote NVMe पर file system mount करने में है.
    • Linux में maximum pipe buffer size 64kB है, इसलिए तकनीकी रूप से dd bs=X argument का उससे बड़ा होना ज़रूरी नहीं है। फिर भी bs=1M नुकसान नहीं करता (यह 64kB reads को 1MB होने तक buffer करता है) और अगर future में pipe size बढ़े तो तब भी उपयोगी रहेगा। netcat के कुछ versions में input और output block size नियंत्रित करने के options होते हैं, जिससे dd bs=X की ज़रूरत कम हो जाती है, लेकिन rescue disks में आम तौर पर ऐसे options के बिना वाला netcat binary इस्तेमाल होता है.

  • nbdkit और nbdcopy का उपयोग करना काफ़ी सरल है.

    • nbdkit file /dev/nvme0n1
    • nbdcopy nbd://otherlaptop localfile

  • जब नया laptop सेट up करना था, तब USB-C cable का उपयोग करके 10Gb/s पर transfer करना उपयोगी रहा। दूसरा विकल्प सिर्फ़ WiFi था.

    • computers को connect करने पर ad-hoc network बन जाता है और rsync का उपयोग करके transfer किया जा सकता है। link saturated लग रहा था, इसलिए कोई दूसरा protocol इस्तेमाल करना बेकार लगता है.

  • हाल ही में WiFi के ज़रिए लगभग 200GB files copy करनी पड़ीं। connection fail होने पर शुरू से फिर शुरू न करना पड़े, इसलिए rsync इस्तेमाल किया, लेकिन फिर भी कम से कम 6 घंटे लगे। इससे बेहतर तरीका क्या हो सकता है, यह जानना चाहता हूँ.

    • dd method से क्या guarantees मिलती हैं? क्या result block-level device का md5 compare करना चाहिए?

  • समझ नहीं आता कि लेखक ने network के ऊपर btrfs pipe क्यों नहीं किया। पहले btrfs snapshot बनाएँ, फिर btrfs send => nc => network => nc => btrfs receive के ज़रिए सिर्फ़ इस्तेमाल में आए blocks transfer करें.

  • पहले जब laptop transfer किए थे, तब दोनों तरफ dd और nc को जोड़ने वाला installer चलाया था। जहाँ तक याद है, transfer तेज़ करने के लिए gzip भी जोड़ा था.

    • नए laptop में Ethernet port नहीं था, इसलिए compression ने थोड़ी speed improvement दी होगी, और शायद यह लेखक के तरीके से तेज़ रहा होगा.

  • Clonezilla का उपयोग करने से सिर्फ़ actual data blocks copy होते हैं और partitions अपने आप adjust हो सकते हैं। मैं हमेशा यही तरीका इस्तेमाल करता हूँ.

    • आम तौर पर NVMe disk को laptop से निकालकर high-speed dock में लगाता हूँ.

  • दशकों से मैंने वास्तव में OS को "install" नहीं किया है; मैं files copy करता हूँ और ज़रूरत के हिसाब से adjust कर लेता हूँ। आम तौर पर इसे नया file system बनाकर file system type/parameters (जैसे block size), encryption आदि update करने और files को rsync से transfer करने के अवसर के रूप में उपयोग करता हूँ.

    • फिर भी, जो लोग पहले से योजना बनाकर चलते हैं, उनके लिए NixOS जैसा ज़्यादा declarative approach बेहतर हो सकता है। यहाँ आप सिर्फ़ configuration copy करके बाकी सब कुछ अपने आप फिर से install कर सकते हैं.

  • FDT(Fast Data Transfer) का कोई ज़िक्र नहीं है.

    • दुर्भाग्य से यह Java में लिखा गया अद्भुत software है (transfer performance के लिहाज़ से)। इसके CLI options सहज नहीं हैं, लेकिन यह मैंने देखा हुआ सबसे तेज़ transfer है.
    • यह इतना तेज़ है कि अगर speed को कृत्रिम रूप से limit न करें, तो कभी-कभी पूरे local network पर क़ब्ज़ा कर लेता है.
    • -limit <rate> option से transfer speed को तय दर तक सीमित किया जा सकता है। suffix के रूप में K(KiloBytes/s), M(MegaBytes/s), G(GigaBytes/s) इस्तेमाल किए जा सकते हैं.
    • यह destination पर file fragmentation पैदा करता है, लेकिन व्यवहार में इससे किसी को फ़र्क नहीं पड़ता.