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

 (copyninja.in)
2 पॉइंट द्वारा GN⁺ 2024-03-13 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • नए लैपटॉप को शुरू से फिर सेट अप करने के बजाय, मौजूदा लैपटॉप की पूरी डिस्क को NVMe over TCP के रूप में expose करके नेटवर्क पर वैसे ही clone किया गया
  • मौजूदा environment में full disk encryption और 512GB डिस्क थी, जबकि नया लैपटॉप 1TB NVMe था, इसलिए cloning के बाद partition, LUKS और BTRFS को expand करना ज़रूरी था
  • डिस्क export करने के लिए systemd-storagetm.service के बजाय दोनों लैपटॉप को GRML rescue CD से boot किया गया और nvmet-tcp व /sys/kernel/config/nvmet से configure किया गया
  • वास्तविक copy dd से की गई; नए लैपटॉप में Ethernet port न होने के कारण सिर्फ WiFi इस्तेमाल करने पर 512GB clone में करीब 7 घंटे 30 मिनट लगे, और speed करीब 18–20MB/s रही
  • cloning के बाद parted, growpart, cryptsetup resize, BTRFS resize के ज़रिए पूरी 1TB capacity इस्तेमाल करने के लिए adjust किया गया, और पुराने लैपटॉप का environment लगभग वैसा ही आगे इस्तेमाल किया जा सका

NVMe over TCP से मौजूदा डिस्क export करना

  • नए लैपटॉप की setup प्रक्रिया दोहराने से बचने के लिए, एक सहकर्मी के सुझाव के अनुसार मौजूदा लैपटॉप की पूरी डिस्क copy करने का तरीका चुना गया

  • शुरू करने से पहले दो अड़चनें थीं

    • पुराने लैपटॉप को खोलकर नई डिस्क को USB से connect करने का tool नहीं था
    • पुराने लैपटॉप में full disk encryption और 512GB डिस्क थी, जबकि नया लैपटॉप 1TB NVMe था, इसलिए LUKS का size adjust करना ज़रूरी था

  • workflow तीन चरणों में चला: डिस्क expose करना, copy करना, और capacity expand करना

    • पुराने लैपटॉप से nvmet-tcp के जरिए डिस्क export की
    • नए लैपटॉप पर उस डिस्क को copy किया
    • partition को पूरी 1TB capacity तक expand किया
    • LUKS का size adjust किया
    • अंत में BTRFS root disk का size adjust किया

  • systemd-storagetm.service के बजाय GRML का इस्तेमाल

    • सबसे आसान तरीके के रूप में systemd-storagetm.service इस्तेमाल किया जा सकता था
    • rd.systemd.unit=storage-target-mode.target specify करके storage-target-mode.target में boot करने पर इसे call किया जा सकता है
    • लेकिन इस तरीके में dracut initrd image में network services शामिल करनी पड़ती हैं, और उस mode में WiFi setup झंझटभरा होने के कारण इसे नहीं चुना गया
    • इसके बजाय दोनों लैपटॉप को GRML rescue CD से boot किया गया, फिर पुराने लैपटॉप पर Linux के nvmet-tcp module से NVMe डिस्क export की गई
    modprobe nvmet-tcp
cd /sys/kernel/config/nvmet
mkdir ports/0
cd ports/0
echo "ipv4" > addr_adrfam
echo 0.0.0.0 > addr_traaddr
echo 4420 > addr_trsvcid
echo tcp > addr_trtype
cd /sys/kernel/config/nvmet/subsystems
mkdir testnqn
echo 1 >testnqn/allow_any_host
mkdir testnqn/namespaces/1
cd testnqn


# replace the device name with the disk you want to export
echo "/dev/nvme0n1" > namespaces/1/device_path
echo 1 > namespaces/1/enable
ln -s "../../subsystems/testnqn" /sys/kernel/config/nvmet/ports/0/subsystems/testnqn
    • इस configuration से target device NVMe over TCP के रूप में expose हो जाता है
    • नए लैपटॉप पर exported device को discover करके connect किया जाता है
    nvme discover -t tcp -a <ip> -s 4420
nvme connectl-all -t tcp -a <> -s 4420
    • इसके बाद nvme list में नए लैपटॉप से connected device की पुष्टि कर सकते हैं और disk copy आगे बढ़ा सकते हैं

डिस्क copy और size adjustment

  • dd से 512GB copy

    • root disk की copy dd command से की गई
    • नए लैपटॉप में Ethernet port न होने के कारण सिर्फ WiFi इस्तेमाल किया गया, और पूरी 512GB copy में करीब 7 घंटे 30 मिनट लगे
    • transfer speed करीब 18–20MB/s रही
    • दूसरे विकल्पों में initial partition और file system बनाने के बाद rsync से root disk copy करना, या BTRFS की अपनी file system transfer सुविधा इस्तेमाल करना शामिल था
    dd if=/dev/nvme2n1 of=/dev/nvme0n1 status=progress bs=40M

  • partition, LUKS, BTRFS expand करना

    • parted ने detect किया कि partition table disk size से match नहीं कर रही है, और confirmation के बाद इसे automatic ठीक कर दिया
    • दूसरे partition को expand करने के लिए cloud-guest-utils install किया गया और growpart इस्तेमाल किया गया
    growpart /dev/nvem0n1 p2
    • अगले चरण में cryptsetup से LUKS container का size बढ़ाया गया
    cryptsetup luksOpen /dev/nvme0n1p2 ENC
cryptsetup resize ENC
    • डिस्क से reboot करने के बाद normal operation confirm किया गया, और login के बाद BTRFS file system का size adjust किया गया
    • BTRFS में size adjustment के लिए system का mounted होना ज़रूरी है, इसलिए live boot state में इसे try नहीं किया जा सकता था
    btfs fielsystem resize max /
    • नतीजतन नए लैपटॉप पर भी पुराने लैपटॉप को जारी रखने जैसा environment मिला
    • आम तौर पर नए लैपटॉप के साथ पूरी तरह सहज होने में करीब 1–2 हफ्ते लगते हैं, लेकिन इस तरीके से वह समय कम हुआ
    • अतिरिक्त रूप से NVMe over TCP से डिस्क export करने का तरीका सीखने का फायदा भी मिला

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

1 टिप्पणियां

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

  • लेखक के scenario में आखिरकार dd(1) से सिर्फ serial block copy ही हो रही है, इसलिए NVMe/TCP इस्तेमाल करने का फायदा बहुत कम है। जटिल command को सरल netcat से बदला जा सकता है
    target laptop: $ nc -l -p 1234 | dd of=/dev/nvme0nX bs=1M
    source laptop: $ nc x.x.x.x 1234
    target side का dd writes को buffer करके उन्हें तेज और ज्यादा efficient बनाने के लिए है। source/target में gzip/gunzip जोड़ दें तो disk पूरी भरी न हो और 0 blocks ज्यादा हों, तो यह काफी तेज हो जाता है। व्यक्तिगत रूप से network पर PC image बनाने का यह मेरा सबसे पसंदीदा तरीका है और मैंने इसे कई बार किया है
    GigE पर compression अक्सर bottleneck बन जाता है, इसलिए gzip को --fast देना बेहतर है, और उससे भी अच्छा gzip/gunzip की जगह lz4/unlz4 इस्तेमाल करें तो यह और तेज होगा। पहले जब GigE पर 1TB NVMe वाले नए Windows laptop की image बनाई थी, तो करीब 20 मिनट लगे थे, और खाली जगह लगभग 0 तक compress हो गई थी, इसलिए final image 20GB की थी। आम तौर पर मैं उस lz4 image का backup रखता हूं और कुछ साल बाद laptop donate करते समय unlz4 | dd से restore कर देता हूं, जो बहुत सुविधाजनक है
    हालांकि Linux kernel module nvme-tcp के बारे में मुझे पता नहीं था; हर दिन कुछ नया सीखने को मिलता है। यह dd से raw access के लिए इस्तेमाल करने के बजाय remote NVMe पर filesystem mount करने में ज्यादा उपयोगी लगता है
    इसके अलावा Linux का maximum pipe buffer size 64kB है, इसलिए dd bs=X argument को तकनीकी रूप से उससे बड़ा होने की जरूरत नहीं है। फिर भी bs=1M नुकसान नहीं करता और 64kB reads को 1MB होने तक इकट्ठा कर देता है, साथ ही भविष्य में pipe size बढ़े तो उसके लिए भी तैयार रहता है। कुछ netcat versions में input/output block size options होते हैं, इसलिए dd bs=X की जरूरत नहीं पड़ती, लेकिन recovery disk का netcat आम तौर पर ऐसे options के बिना वाला version होता है

    • Linux का pipe buffer बढ़ाया जा सकता है, और default maximum value आम तौर पर करीब 1MB होती है, ऐसा मेरी जानकारी है। command line से करना थोड़ा tricky है, लेकिन संभव implementation example https://unix.stackexchange.com/a/328364 पर है
    • थोड़ा messy जरूर है, लेकिन दोनों तरफ dd के बजाय pv इस्तेमाल करें तो सही block size specify करने की चिंता नहीं रहती, और progress graph भी अच्छा दिखता है
    • करीब 9 साल पहले मैं एक ऐसी company में consulting के लिए गया था, जिसे internal hack का सामना करना पड़ा था। एक नाराज co-founder ने deadman switch जैसा कुछ लगा रखा था, जिससे सभी disks के पहले 20MB किसी bucket में copy होकर फिर 0 से overwrite हो जाते थे। data recover करने के लिए testdisk से partition table फिर से बनानी पड़ी, लेकिन उससे पहले damaged disks को छूना नहीं चाहता था, इसलिए recovery flash disk, netcat और drives के जरिए करीब 40TB copy किया
      कुछ servers में physical RAID slots सभी भरे हुए थे, इसलिए spare disk slot भी इस्तेमाल नहीं कर सकते थे, और मोटे तौर पर dd if=/dev/sdc bs=xxx | gzip | nc -l -p 8888 और दूसरी तरफ उसका reverse command इस्तेमाल किया। हैरानी की बात है कि यह अच्छी तरह चला। एक बात का ध्यान रखना चाहिए कि dd bs combination को sector size के हिसाब से आजमाएं, क्योंकि सही size का dd throughput पर बड़ा असर पड़ा
    • dd का यह इस्तेमाल corruption कर सकता है। blocks कटें नहीं, इसके लिए iflag=fullblock चाहिए, और भले ही यह अंधी practice होने का जोखिम रखता हो, conv=sync भी नुकसानदेह नहीं है। व्यक्तिगत रूप से मैं बस nc -l -p 1234 > /dev/nvme0nX पसंद करता हूं
    • ज्यादातर मामलों में local network, SSD transfer speed से तेज नहीं होगा। फिर भी जिनके पास ऐसा environment है, उनके लिए क्या कोई simultaneous I/O block device cloning tool मौजूद है, यह जानने की इच्छा है
      pipeline में pv डालें तो estimated completion time दिख सकता है, लेकिन performance पर थोड़ा असर पड़ सकता है

  • AWS/Annapurna/Nitro/Lightbits को Linux में NVMe-over-TCP लाने के लिए धन्यवाद
    https://www.techtarget.com/searchstorage/news/252459311/Ligh...
    “NVM Express consortium ने नवंबर 2018 में NVMe/TCP को binding transport layer के रूप में ratify किया। यह standard मूल रूप से Lightbits engineering team द्वारा NVM Express को submit किए गए code base से विकसित हुआ।”
    https://www.lightbitslabs.com/blog/linux-distributions-nvme-...
    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

  • नीचे वाले तरीके की तुलना में यह कहीं ज्यादा झंझट वाला लगता है: nbdkit file /dev/nvme0n1, nbdcopy nbd://otherlaptop localfile

    • यह तरीका वाकई काफी बेहतर है, क्योंकि nbdcopy sparse files handle कर सकता है, connections और threads की संख्या cores की संख्या के अनुसार set कर सकता है, exit से पहले forced flush भी कर सकता है और progress bar भी enable कर सकता है। अगर drive encrypted नहीं है, तो TLS भी support करता है

  • हाल ही में नए लैपटॉप पर xubuntu install करना पड़ा। पहले मैं clone करता था, लेकिन इस बार कुछ settings नए सिरे से व्यवस्थित करना चाहता था
    USB-C cable से 10Gb/s transfer करना वाकई उपयोगी रहा, क्योंकि दूसरा विकल्प सिर्फ WiFi था
    कंप्यूटरों को आपस में plug करने पर एक temporary network बन जाता है और बस rsync से भेज देना होता है। देखने में link saturated लग रहा था, इसलिए कोई दूसरा protocol इस्तेमाल करने का खास मतलब नहीं दिखा। बेशक नई चीज़ सीखना अच्छा है, लेकिन शायद लैपटॉप clone करने के समय नहीं

    • जानना चाहता हूँ कि क्या यह बस सीधे काम कर गया था। आखिरी बार मैंने Ethernet के अलावा direct connection 90s में try किया था, इसलिए सच में पूछ रहा हूँ
    • मैंने भी किया है, लेकिन networking चलाने के लिए 30 डॉलर से ज़्यादा वाला Thunderbolt 4 cable खरीदना पड़ा। सामान्य USB3-C cable पर्याप्त नहीं था
      transfer खुद बेहद तेज़ था, कुछ ही मिनटों में 1TB move हो गया। इस बार encryption नहीं इस्तेमाल किया, इसलिए सब बहुत आसान रहा
    • जिज्ञासा है कि live disk से boot करके पूरा filesystem move किया था, या पहले base system install करके फिर सिर्फ files move की थीं

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

    • जैसे ही देखा कि btrfs इस्तेमाल हुआ है, मेरे मन में भी सबसे पहले यही आया। btrfs send/receive को SSH के साथ हमेशा इस्तेमाल करता हूँ और यह बहुत अच्छा काम करता है। GRML live session में SSH server आसानी से शुरू किया जा सकता था
      हालांकि एक सावधानी है। btrfs में snapshots को recursively भेजा नहीं जा सकता, इसलिए अगर बहुत सारे recursive snapshots हों तो नई disk पर वही structure mirror करना अपेक्षाकृत मुश्किल है। Docker/LXD/Incus में ऐसा हो सकता है। btrfs पसंद है, लेकिन recursive send/receive में ZFS बेहतर है

  • हाल ही में WiFi पर करीब 200GB files copy करनी पड़ीं। connection fail होने पर शुरुआत से फिर शुरू न करना पड़े और कोई loss न हो, इसलिए rsync इस्तेमाल किया, लेकिन कम-से-कम 6 घंटे लगे। सोच रहा हूँ क्या कोई बेहतर तरीका था
    और यह भी जानना चाहता हूँ कि dd वाला तरीका क्या guarantees देता है। क्या result block device का md5 compare करना चाहिए?

    • WiFi पर 200GB ले जाने में 6 घंटे लगना local transfer के लिए प्रभावशाली throughput नहीं है। शायद Ethernet cable इस्तेमाल करनी चाहिए थी
      WiFi में performance bottleneck के कारण कहीं ज़्यादा होते हैं। सिर्फ एक device को भी cable से router में जोड़कर और दूसरे को wireless रखने से काफी मदद मिलती है
    • अगर files बहुत ज़्यादा और छोटी थीं, तो संभव है bottleneck यह था कि rsync एक बार में केवल एक file transfer करता है। xargs/parallel से file list बाँटकर कई rsync instances चला सकते हैं, या rclone जैसी चीज़ इस्तेमाल कर सकते हैं जो अपने-आप parallel transfer support करती है
    • 6 घंटे यानी मोटे तौर पर 10MB/s, इसलिए बहुत तेज़ करना संभव रहा होगा। जिज्ञासा है कि -z से compression किया था या नहीं। अगर Ethernet इस्तेमाल कर सकते थे, तो अधिकतर devices पर 100MB/s के करीब पहुँच जाते और लगभग 35 मिनट लगते
    • अगर rsync का transfer method SSH था, तो अक्सर वही bottleneck होता है। OpenSSH में ऐतिहासिक रूप से अजीब performance limits रही हैं, और उन्हें bypass करने के लिए कभी-कभी कम-ज्ञात patches की ज़रूरत पड़ती थी। अगर CPU bottleneck नहीं है, तो compression on करना भी मदद करता है
    • WiFi बाकी सभी wireless devices के साथ हवा नाम का medium share करता है। collision detect होने पर यह रुकता है और random समय तक इंतज़ार करता है
      “computer networking में collision avoidance वाला carrier-sense multiple access (CSMA/CA) एक network multiple access method है जो carrier sensing इस्तेमाल करता है, लेकिन channel को ‘idle’ detect करने के बाद ही transmission शुरू करके collisions से बचने की कोशिश करता है। transmit करते समय node packet data को पूरा transmit करता है
      यह wireless networks में खास तौर पर महत्वपूर्ण है, क्योंकि wireless transmitter packet transmission के दौरान receiver को insensitive बनाकर effectively बंद कर देता है, इसलिए collision detection method CSMA/CD इस्तेमाल नहीं किया जा सकता
      hidden node problem के कारण CSMA/CA कम reliable है
      CSMA/CA data link layer पर काम करने वाला protocol है।”
      https://en.wikipedia.org/wiki/Carrier-sense_multiple_access_...

  • इस approach के अपने फायदे होंगे, लेकिन पहले जब laptop migrate किया था तो दोनों तरफ installer चलाकर dd और nc को combine किया था। याद है कि बड़े null regions को तेज़ी से transfer करने के लिए gzip भी जोड़ा था
    अगर नए laptop में Ethernet port नहीं था, तो मेरा hacky तरीका compression की वजह से थोड़ा तेज़ हो सकता था। क्योंकि network speed इतनी fast link पर compression से आने वाली limit के करीब नहीं पहुँच रही होती

    • अगर full disk encryption enabled है, तो जब तक LUKS को TRIM pass-through करने को न कहा गया हो, लेखक द्वारा बताए तरीके से असल में random data ही मिलेगा

  • बस Clonezilla इस्तेमाल क्यों नहीं कर लेते? यह केवल actual data blocks copy करता है और partition auto-resize भी कर सकता है। मैं हमेशा यही करता हूँ
    हालांकि आम तौर पर मैं laptop से NVMe disk निकालकर high-speed dock में लगाता हूँ

    • Clonezilla शानदार है। इसका एक ही काम है और आम तौर पर पहली कोशिश में सफल हो जाता है। बस शुरुआती learning curve की वजह से थोड़ा इधर-उधर प्रयोग करना पड़ता है, यही एक शिकायत है
      अभी यह पूरी तरह भरोसा करके छोड़ देने लायक नहीं है। backup, backup और restore के योग के बराबर नहीं होता, इसलिए experiment करना recommended है। Clonezilla को भी source से काफी अलग disk पर partitions recreate करते समय problems आ सकती हैं

  • desktop या laptop पर operating system सच में “install” किए दशकों हो गए; हमेशा files copy कीं और फिर ज़रूरी हिस्से adjust किए। आम तौर पर इस मौके पर filesystem type या block size जैसे parameters, encryption वगैरह update करने के लिए नया filesystem बनाता हूँ और rsync से files move करता हूँ
    फिर भी अगर आप पहले से plan करने वाले type हैं, तो settings ही copy करके बाकी सब automated reinstall करने वाला NixOS जैसा ज़्यादा declarative approach बेहतर हो सकता है

  • बीच में AP के बिना WiFi से devices को directly connect करें तो transfer speed दोगुनी की जा सकती है। इस situation में इसे try करना worthwhile रहा होगा