โคลนโน้ตบุ๊กผ่าน NVMe TCP

 (copyninja.in)
2 คะแนน โดย GN⁺ 2024-03-13 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

โคลนโน้ตบุ๊กด้วย NVME TCP

  • เพิ่งซื้อโน้ตบุ๊กเครื่องใหม่ และต้องตั้งค่าให้พร้อมใช้งาน
  • ไม่มีแรงจูงใจจะทำตามขั้นตอนเดิม ๆ ที่คุ้นเคยอีกครั้ง
  • จากคำแนะนำของเพื่อนร่วมงาน จึงพิจารณาวิธีคัดลอกดิสก์เดิมไปยังโน้ตบุ๊กเครื่องใหม่

ข้อสงสัยเกี่ยวกับกระบวนการโคลน

  • ไม่มีอุปกรณ์สำหรับเปิดโน้ตบุ๊กเครื่องเดิมและเชื่อมต่อดิสก์ใหม่ผ่าน USB
  • ใช้การเข้ารหัสดิสก์ทั้งลูกอยู่ โดยโน้ตบุ๊กเครื่องเดิมใช้ NVME ขนาด 512GB และเครื่องใหม่ใช้ NVME ขนาด 1TB
  • ไม่คุ้นเคยกับการปรับขนาดพาร์ทิชัน LUKS

ข้อเสนอของเพื่อนร่วมงาน

  • แนะนำให้ใช้ NVME over TCP เพื่อแชร์ดิสก์ผ่านเครือข่ายและทำการคัดลอกดิสก์ทั้งลูก
  • ขั้นตอนที่แนะนำมีดังนี้:
    • ส่งออกดิสก์จากโน้ตบุ๊กเครื่องเดิมด้วย nvmet-tcp
    • คัดลอกดิสก์ไปยังโน้ตบุ๊กเครื่องใหม่
    • ปรับขนาดพาร์ทิชันให้ใช้พื้นที่เต็ม 1TB
    • ปรับขนาด LUKS
    • สุดท้ายปรับขนาดดิสก์รากของ BTRFS

การส่งออกดิสก์ผ่าน NVME TCP

  • มีการแนะนำว่าใช้ systemd-storagetm.service จะเป็นวิธีที่ง่ายที่สุด
  • แต่เลือกบูตโน้ตบุ๊กทั้งสองเครื่องด้วย GRML rescue CD และทำตามขั้นตอนการส่งออกดิสก์ NVME ด้วยโมดูล nvmet-tcp

การคัดลอกดิสก์

  • ใช้คำสั่ง dd เพื่อคัดลอกดิสก์รากไปยังโน้ตบุ๊กเครื่องใหม่
  • โน้ตบุ๊กเครื่องใหม่ไม่มีพอร์ตอีเธอร์เน็ต จึงต้องใช้ Wi-Fi เท่านั้น และใช้เวลาประมาณ 7 ชั่วโมงครึ่งในการคัดลอกทั้งหมด 512GB
  • ความเร็วในการคัดลอกอยู่ที่ประมาณ 18-20MB/s

การปรับขนาดพาร์ทิชันและคอนเทนเนอร์ LUKS

  • เมื่อรัน parted พบว่าตารางพาร์ทิชันไม่ตรงกับขนาดดิสก์ และมีการขอให้แก้ไข
  • ติดตั้ง cloud-guest-utils แล้วใช้ growpart เพื่อขยายพาร์ทิชันเป็น 1TB
  • ใช้ cryptsetup-resize เพื่อเพิ่มขนาดคอนเทนเนอร์ LUKS
  • หลังจากล็อกอินเข้าสู่ระบบแล้ว จึงปรับขนาดไฟล์ซิสเต็ม BTRFS

บทสรุป

  • ข้อดีเพียงอย่างเดียวของกระบวนการนี้คือสามารถใช้งานโน้ตบุ๊กเครื่องใหม่ได้ด้วยความรู้สึกเหมือนกำลังใช้เครื่องเดิม
  • ปกติการตั้งค่าโน้ตบุ๊กใหม่มักใช้เวลา 1-2 สัปดาห์ แต่ในกรณีนี้สามารถประหยัดเวลานั้นได้
  • อีกข้อดีคือได้เรียนรู้วิธีส่งออกดิสก์ด้วย NVME over TCP

ความเห็นของ GN⁺

  • การโคลนโน้ตบุ๊กด้วย NVME over TCP เป็นแนวทางที่มีประสิทธิภาพสำหรับการย้ายสภาพแวดล้อมระบบเดิมไปยังฮาร์ดแวร์ใหม่อย่างรวดเร็ว
  • เทคโนโลยีนี้น่าสนใจสำหรับผู้ดูแลระบบหรือผู้พัฒนาที่ต้องการประหยัดเวลาและลดความผิดพลาดจากการตั้งค่า
  • อย่างไรก็ตาม วิธีนี้พึ่งพาความเร็วเครือข่ายอย่างมาก และหากใช้ได้แค่ Wi-Fi ก็อาจต้องใช้เวลานาน ซึ่งเป็นข้อเสียที่ควรคำนึงถึง
  • แม้จะมีเครื่องมืออย่าง Clonezilla หรือ Acronis ที่ให้ความสามารถคล้ายกัน แต่ NVME over TCP มีจุดเด่นเฉพาะตัวคือการเข้าถึงดิสก์โดยตรงผ่านเครือข่าย
  • การนำเทคโนโลยีนี้มาใช้ต้องอาศัยความรู้เพียงพอเกี่ยวกับการตั้งค่าเครือข่าย การจัดการดิสก์ที่เข้ารหัส และการปรับขนาดไฟล์ซิสเต็ม

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-03-13
ความคิดเห็นบน Hacker News

  • ในกรณีการใช้งานของผู้เขียน ไม่มีข้อดีจากการใช้ NVMe/TCP เลย เพราะแค่ใช้ dd เพื่อคัดลอกบล็อกแบบอนุกรม จึงไม่ได้ใช้ประโยชน์จาก I/O พร้อมกัน คำสั่งที่ซับซ้อนสามารถแทนที่ด้วย netcat แบบง่าย ๆ ได้

    • บนโน้ตบุ๊กปลายทาง ใช้ $ nc -l -p 1234 | dd of=/dev/nvme0nX bs=1M
    • บนโน้ตบุ๊กต้นทาง ใช้ $ nc x.x.x.x 1234 </dev/nvme0nX
    • บนปลายทาง dd จะบัฟเฟอร์การเขียน ทำให้เร็วและมีประสิทธิภาพมากขึ้น หากเพิ่ม gzip/gunzip ที่ฝั่งต้นทาง/ปลายทางด้วย งานทั้งหมดจะเร็วขึ้นมากเมื่อดิสก์ไม่ได้เต็ม วิธีนี้เป็นวิธีโปรดในการสร้างอิมเมจ PC ผ่านเครือข่าย แนะนำให้ส่งตัวเลือก --fast ให้ gzip หรือเปลี่ยนไปใช้ lz4/unlz4 ที่เร็วกว่า เมื่อไม่นานมานี้เคยใช้กับการทำอิมเมจโน้ตบุ๊ก Windows ใหม่ที่มี NVMe 1TB ใช้เวลาประมาณ 20 นาทีผ่าน GigE และอิมเมจที่ได้มีขนาด 20GB ปกติจะเก็บอิมเมจ lz4 นี้ไว้สำรอง และอีกหลายปีต่อมาเมื่อบริจาคโน้ตบุ๊กก็ค่อยกู้คืนด้วย unlz4 | dd สะดวกมาก
    • ไม่เคยรู้จัก Linux kernel module nvme-tcp มาก่อน แต่ได้เรียนรู้อะไรใหม่ทุกวัน ประโยชน์ของโมดูลนี้น่าจะอยู่ที่การเมานต์ไฟล์ซิสเต็มบน NVMe ระยะไกลมากกว่าการเข้าถึงดิบด้วย dd
    • บน Linux ขนาดบัฟเฟอร์ pipe สูงสุดคือ 64kB ดังนั้นอาร์กิวเมนต์ dd bs=X จึงในทางเทคนิคไม่จำเป็นต้องใหญ่กว่านั้น อย่างไรก็ตาม bs=1M ก็ไม่ได้มีผลเสียใด ๆ (มันจะบัฟเฟอร์การอ่าน 64kB ไปจนกว่าจะครบ 1MB) และยังใช้ได้ในอนาคตหากขนาด pipe เพิ่มขึ้น netcat บางเวอร์ชันมีตัวเลือกสำหรับควบคุมขนาดบล็อกอินพุตและเอาต์พุต ซึ่งช่วยลดความจำเป็นในการใช้ dd bs=X แต่ในดิสก์กู้ระบบแบบบูตได้มักใช้ไบนารี netcat ที่ไม่มีตัวเลือกเหล่านี้

  • การใช้ nbdkit และ nbdcopy ง่ายกว่ามาก

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

  • ตอนที่ต้องตั้งค่าโน้ตบุ๊กเครื่องใหม่ การส่งข้อมูลผ่านสาย USB-C ที่ 10Gb/s มีประโยชน์มาก อีกทางเลือกเดียวคือ WiFi

    • เมื่อเชื่อมต่อคอมพิวเตอร์เข้าด้วยกัน จะเกิดเครือข่าย ad hoc และสามารถส่งผ่าน rsync ได้ ดูเหมือนลิงก์จะอิ่มตัวอยู่แล้ว ดังนั้นการใช้โปรโตคอลอื่นก็ไม่มีความหมาย

  • ไม่นานมานี้ต้องคัดลอกไฟล์ประมาณ 200GB ผ่าน WiFi ใช้ rsync เพื่อไม่ให้ต้องเริ่มใหม่ตั้งแต่ต้นหากการเชื่อมต่อล้มเหลว แต่ก็ยังใช้เวลาอย่างน้อย 6 ชั่วโมง เลยสงสัยว่ามีวิธีที่ดีกว่านี้ไหม

    • วิธี dd ให้หลักประกันอะไรบ้าง? ต้องเทียบ md5 ของอุปกรณ์ระดับบล็อกที่ได้ผลลัพธ์หรือไม่?

  • ไม่เข้าใจว่าทำไมผู้เขียนไม่ pipe btrfs ผ่านเครือข่าย สร้าง snapshot ของ btrfs ก่อน แล้วใช้ btrfs send => nc => network => nc => btrfs receive เพื่อส่งเฉพาะบล็อกที่ใช้งานอยู่

  • ก่อนหน้านี้เวลาโอนย้ายโน้ตบุ๊ก เคยรันตัวติดตั้งที่รวม dd และ nc ไว้ทั้งสองฝั่ง เท่าที่จำได้ก็เพิ่ม gzip เพื่อให้การส่งเร็วขึ้นด้วย

    • โน้ตบุ๊กเครื่องใหม่ไม่มีพอร์ตอีเธอร์เน็ต ดังนั้นการบีบอัดอาจช่วยเพิ่มความเร็วได้บ้าง และน่าจะเร็วกว่าวิธีของผู้เขียน

  • ถ้าใช้ Clonezilla จะคัดลอกเฉพาะบล็อกข้อมูลจริงและปรับพาร์ทิชันให้อัตโนมัติ ใช้วิธีนี้ตลอด

    • โดยทั่วไปจะถอดดิสก์ NVMe ออกจากโน้ตบุ๊กแล้วใส่ในด็อกความเร็วสูง

  • หลายสิบปีแล้วที่ไม่ได้ "ติดตั้ง" OS แบบจริงจัง แต่คัดลอกไฟล์แล้วปรับตามต้องการ ปกติใช้โอกาสนี้สร้างไฟล์ซิสเต็มใหม่เพื่ออัปเดตประเภท/พารามิเตอร์ของไฟล์ซิสเต็ม (เช่น ขนาดบล็อก) การเข้ารหัส เป็นต้น แล้วส่งไฟล์ด้วย rsync

    • ถึงอย่างนั้น ถ้าเป็นคนที่ชอบวางแผน อาจใช้แนวทางเชิงประกาศมากกว่าอย่าง NixOS จะดีกว่า เพราะในกรณีนั้นแค่คัดลอกการตั้งค่าแล้วให้ระบบติดตั้งทุกอย่างใหม่โดยอัตโนมัติได้

  • ไม่มีการพูดถึง FDT (Fast Data Transfer) เลย

    • น่าเสียดายที่มันเป็นซอฟต์แวร์ยอดเยี่ยมที่เขียนด้วย Java (ในแง่ประสิทธิภาพการรับส่งข้อมูล) มันมีตัวเลือก CLI ที่ไม่ค่อยตรงไปตรงมา แต่เป็นการส่งข้อมูลที่เร็วที่สุดเท่าที่เคยเห็นมา
    • มันเร็วมากจนบางครั้งถ้าไม่จำกัดความเร็วแบบตั้งใจ ก็จะกินแบนด์วิดท์ของเครือข่ายภายในทั้งหมด
    • สามารถใช้ตัวเลือก -limit <rate> เพื่อจำกัดความเร็วการส่งตามอัตราที่กำหนดได้ โดยใช้ K(KiloBytes/s), M(MegaBytes/s), G(GigaBytes/s) เป็น suffix ได้
    • มันทำให้เกิดการกระจายตัวของไฟล์ที่ปลายทาง แต่ในทางปฏิบัติก็ไม่ได้สำคัญกับใครนัก