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

 (copyninja.in)
2 คะแนน โดย GN⁺ 2024-03-13 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • แทนที่จะตั้งค่าโน้ตบุ๊กเครื่องใหม่ตั้งแต่ต้น ผู้เขียนเลือก เปิดเผยทั้งดิสก์ของโน้ตบุ๊กเครื่องเดิมผ่าน NVMe over TCP แล้วโคลนผ่านเครือข่ายแบบเดิมทั้งหมด
  • สภาพแวดล้อมเดิมใช้ การเข้ารหัสดิสก์ทั้งลูก และดิสก์ขนาด 512GB ส่วนโน้ตบุ๊กใหม่ใช้ NVMe 1TB จึงต้องขยายพาร์ทิชัน, LUKS และ BTRFS หลังโคลนเสร็จ
  • แทนการใช้ systemd-storagetm.service ผู้เขียนบูตโน้ตบุ๊กทั้งสองเครื่องด้วย GRML rescue CD แล้วตั้งค่า nvmet-tcp และ /sys/kernel/config/nvmet
  • การคัดลอกจริงทำด้วย dd และเนื่องจากโน้ตบุ๊กใหม่ไม่มีพอร์ตอีเธอร์เน็ตจึง ใช้ได้แค่ WiFi ทำให้การโคลน 512GB ใช้เวลาราว 7 ชั่วโมง 30 นาที ที่ความเร็วประมาณ 18~20MB/s
  • หลังโคลน ผู้เขียนใช้ parted, growpart, cryptsetup resize และ BTRFS resize เพื่อปรับให้ใช้พื้นที่ 1TB ได้ทั้งหมด และสภาพแวดล้อมเดิมก็ถูกย้ายมาต่อได้แทบทั้งหมด

ส่งออกดิสก์เดิมผ่าน NVMe over TCP

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

  • ก่อนเริ่มมีอุปสรรคอยู่สองอย่าง

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

  • ลำดับงานแบ่งเป็นสามขั้น: เปิดเผยดิสก์, คัดลอก, และขยายความจุ

    • ส่งออกดิสก์จากโน้ตบุ๊กเดิมด้วย nvmet-tcp
    • คัดลอกดิสก์นั้นบนโน้ตบุ๊กใหม่
    • ขยายพาร์ทิชันให้เต็ม 1TB
    • ปรับขนาด LUKS
    • สุดท้ายปรับขนาดดิสก์รากของ BTRFS

  • ใช้ GRML แทน systemd-storagetm.service

    • วิธีที่ง่ายที่สุดคือใช้ systemd-storagetm.service
    • สามารถเรียกใช้ได้โดยกำหนด rd.systemd.unit=storage-target-mode.target เพื่อบูตเข้า storage-target-mode.target
    • แต่แนวทางนี้ต้องใส่บริการเครือข่ายไว้ในอิมเมจ dracut initrd และในโหมดนั้น การตั้งค่า WiFi ยุ่งยาก จึงไม่ได้เลือกใช้
    • ผู้เขียนจึงบูตโน้ตบุ๊กทั้งสองเครื่องด้วย GRML rescue CD แล้วใช้โมดูล nvmet-tcp ของ Linux เพื่อส่งออกดิสก์ NVMe จากเครื่องเดิม
    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
    • ด้วยการตั้งค่านี้ อุปกรณ์เป้าหมายจะถูกเปิดเผยผ่าน NVMe over TCP
    • บนโน้ตบุ๊กใหม่ ให้ค้นหาและเชื่อมต่ออุปกรณ์ที่ถูกส่งออกมา
    nvme discover -t tcp -a <ip> -s 4420
nvme connectl-all -t tcp -a <> -s 4420
    • จากนั้นตรวจสอบอุปกรณ์ที่เชื่อมต่อบนโน้ตบุ๊กใหม่ได้ด้วย nvme list แล้วจึงเริ่มคัดลอกดิสก์

คัดลอกดิสก์และปรับขนาด

  • คัดลอก 512GB ด้วย dd

    • การคัดลอกดิสก์รากทำด้วยคำสั่ง dd
    • เนื่องจากโน้ตบุ๊กใหม่ ไม่มีพอร์ตอีเธอร์เน็ตและใช้ได้แค่ WiFi การคัดลอก 512GB ทั้งหมดจึงใช้เวลาประมาณ 7 ชั่วโมง 30 นาที
    • ความเร็วในการส่งข้อมูลอยู่ที่ราว 18~20MB/s
    • ทางเลือกอื่นคือสร้างพาร์ทิชันและไฟล์ระบบเบื้องต้นก่อนแล้วคัดลอกดิสก์รากด้วย rsync หรือใช้การส่งไฟล์ระบบของ BTRFS โดยตรง
    dd if=/dev/nvme2n1 of=/dev/nvme0n1 status=progress bs=40M

  • ขยายพาร์ทิชัน, LUKS และ BTRFS

    • parted ตรวจพบว่าตารางพาร์ทิชันไม่ตรงกับขนาดดิสก์ และหลังถามยืนยันก็แก้ไขให้อัตโนมัติ
    • เพื่อขยายพาร์ทิชันที่สอง ผู้เขียนติดตั้ง cloud-guest-utils และใช้ growpart
    growpart /dev/nvem0n1 p2
    • ขั้นถัดไปคือขยายขนาด คอนเทนเนอร์ LUKS ด้วย cryptsetup
    cryptsetup luksOpen /dev/nvme0n1p2 ENC
cryptsetup resize ENC
    • หลังจากนั้นผู้เขียนรีบูตเข้าดิสก์และยืนยันว่าระบบทำงานปกติ แล้วจึงล็อกอินเพื่อปรับขนาดไฟล์ระบบ BTRFS
    • BTRFS ต้องเมานต์ระบบอยู่จึงจะปรับขนาดได้ ดังนั้นจึง ไม่สามารถทำในสถานะบูตแบบไลฟ์ได้
    btfs fielsystem resize max /
    • ผลลัพธ์คือบนโน้ตบุ๊กใหม่ก็ได้สภาพแวดล้อมที่เหมือนยังใช้งานเครื่องเดิมอยู่
    • โดยปกติการปรับตัวกับโน้ตบุ๊กเครื่องใหม่อย่างสมบูรณ์มักใช้เวลาประมาณ 1~2 สัปดาห์ แต่วิธีนี้ช่วยลดเวลานั้นลง
    • อีกสิ่งที่ได้เพิ่มเติมคือได้เรียนรู้ วิธีส่งออกดิสก์ผ่าน NVMe over TCP

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

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

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

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

    • บัฟเฟอร์ของ pipe ใน Linux ปรับเพิ่มได้ และเท่าที่รู้ค่าสูงสุดเริ่มต้นมักอยู่ราว 1MB ทำผ่านบรรทัดคำสั่งจะยุ่งนิดหน่อยแต่ทำได้ ตัวอย่างการทำงานมีที่ https://unix.stackexchange.com/a/328364
    • แม้จะดูรกนิดหน่อย แต่ถ้าใช้ pv แทน dd ทั้งสองฝั่ง ก็ไม่ต้องกังวลเรื่องกำหนดขนาดบล็อกให้เหมาะสม และยังได้กราฟความคืบหน้าที่ดูสวยด้วย
    • เมื่อราว 9 ปีก่อน เคยไปเป็นที่ปรึกษาให้บริษัทที่โดนแฮ็กจากภายใน โดยผู้ร่วมก่อตั้งที่ไม่พอใจได้ตั้งเดดแมนสวิตช์ไว้ให้คัดลอก 20MB แรกของทุกดิสก์ไปยังบักเก็ตแห่งหนึ่งแล้วเขียนทับด้วย 0 เพื่อกู้ข้อมูล เราต้องใช้ testdisk สร้างตารางพาร์ทิชันกลับขึ้นมาใหม่ แต่ก่อนหน้านั้นไม่อยากแตะต้องดิสก์ที่เสียหาย จึงคัดลอกข้อมูลประมาณ 40TB ด้วยแฟลชดิสก์กู้คืน, netcat และไดรฟ์
      เซิร์ฟเวอร์บางเครื่องมีสล็อต RAID แบบกายภาพเต็มหมด จึงใส่ดิสก์สำรองเพิ่มไม่ได้ และใช้คำสั่งประมาณ dd if=/dev/sdc bs=xxx | gzip | nc -l -p 8888 กับคำสั่งย้อนกลับอีกฝั่งหนึ่ง ซึ่งทำงานได้ดีเกินคาด สิ่งหนึ่งที่ต้องระวังคือทดลองจับคู่ dd bs ให้เข้ากับขนาดเซกเตอร์ เพราะขนาดที่เหมาะสมส่งผลต่อ throughput ของ dd อย่างมาก
    • การใช้ dd แบบนี้อาจทำให้เกิด ความเสียหาย ได้ ต้องมี iflag=fullblock เพื่อไม่ให้บล็อกถูกตัด และแม้จะเสี่ยงเป็นธรรมเนียมที่ทำตาม ๆ กันโดยไม่คิด แต่ conv=sync ก็ไม่ได้มีโทษอะไร ส่วนตัวแล้วชอบใช้ nc -l -p 1234 > /dev/nvme0nX ตรง ๆ มากกว่า
    • สำหรับคนส่วนใหญ่ เครือข่ายภายในน่าจะไม่ได้เร็วกว่าอัตราการส่งข้อมูลของ SSD ถึงอย่างนั้นก็สงสัยว่ามี เครื่องมือโคลนอุปกรณ์บล็อกแบบ I/O พร้อมกัน สำหรับคนที่มีสภาพแวดล้อมแบบนั้นหรือไม่
      ถ้าใส่ pv เข้าไปใน pipeline จะเห็นเวลาที่คาดว่าจะเสร็จได้ แต่ก็อาจมีผลกับประสิทธิภาพเล็กน้อย

  • ขอขอบคุณ AWS/Annapurna/Nitro/Lightbits ที่นำ NVMe-over-TCP มาสู่ Linux
    https://www.techtarget.com/searchstorage/news/252459311/Ligh...
    “สมาคม NVM Express ให้สัตยาบัน NVMe/TCP เป็น binding transport layer ในเดือนพฤศจิกายน 2018 มาตรฐานนี้พัฒนาต่อยอดมาจากโค้ดเบสที่ทีมวิศวกรรมของ Lightbits ส่งให้ NVM Express ในตอนแรก”
    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 ได้ และสามารถปรับจำนวนการเชื่อมต่อกับจำนวนเธรดให้เหมาะกับจำนวนคอร์ได้ รวมถึงบังคับ flush ก่อนจบงานได้ และยังเปิดแถบความคืบหน้าได้ด้วย ถ้าไดรฟ์ไม่ได้เข้ารหัสก็รองรับ TLS เช่นกัน

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

    • อยากรู้ว่ามันใช้งานได้ทันทีเลยไหม ครั้งสุดท้ายที่ฉันลองเชื่อมต่อโดยตรงแบบไม่ผ่านอีเธอร์เน็ตคือยุค 90 เลยถามจริงจัง
    • ฉันก็เคยลอง แต่ถ้าจะให้ระบบเครือข่ายใช้งานได้ต้องซื้อ สาย Thunderbolt 4 ราคาเกิน 30 ดอลลาร์ สาย USB3-C ทั่วไปอย่างเดียวไม่พอ
      ตัวการโอนเร็วมาก ย้าย 1TB เสร็จในไม่กี่นาที ครั้งนี้ไม่ได้ใช้การเข้ารหัสด้วยเลยง่ายขึ้นมาก
    • อยากรู้ว่าคุณบูตจากไลฟ์ดิสก์แล้วค่อยย้ายทั้งไฟล์ซิสเต็ม หรือว่าติดตั้งระบบพื้นฐานก่อนแล้วค่อยย้ายเฉพาะไฟล์

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

    • พอเห็นว่าใช้ btrfs ฉันก็นึกถึงเรื่องนี้เป็นอย่างแรกเหมือนกัน ฉันใช้ btrfs send/receive ผ่าน SSH ตลอดและมันทำงานได้ดีมาก น่าจะเปิด SSH server จากไลฟ์เซสชันของ GRML ได้ไม่ยากด้วย
      แต่มีข้อควรระวังอย่างหนึ่งคือใน btrfs ไม่สามารถส่ง snapshot แบบ recursive ได้ ดังนั้นถ้ามี recursive snapshot เยอะ การ mirror โครงสร้างเดียวกันไปยังดิสก์ใหม่จะค่อนข้างยาก เรื่องนี้อาจเกิดกับ Docker/LXD/Incus ได้ ฉันชอบ btrfs นะ แต่เรื่อง recursive send/receive นี่ ZFS ทำได้ดีกว่า

  • เมื่อเร็ว ๆ นี้ต้องคัดลอกไฟล์ขนาดประมาณ 200GB ผ่าน WiFi อยากให้ถ้าการเชื่อมต่อล้มเหลวจะได้ไม่ต้องเริ่มใหม่ตั้งแต่ต้น และไม่ให้ข้อมูลสูญหาย เลยใช้ rsync แต่ใช้เวลาอย่างน้อย 6 ชั่วโมง เลยสงสัยว่ามีวิธีที่ดีกว่านี้ไหม
    แล้ววิธีแบบ dd ให้การรับประกันอะไรบ้าง ต้องเอา md5 ของ block device ปลายทางมาเทียบหรือเปล่า?

    • 200GB ผ่าน WiFi ใช้เวลา 6 ชั่วโมงถือว่าไม่ใช่ throughput ที่น่าประทับใจสำหรับการโอนในเครื่องเครือข่ายท้องถิ่น น่าจะใช้ สายอีเธอร์เน็ต มากกว่า
      WiFi มีปัจจัยคอขวดด้านประสิทธิภาพได้เยอะกว่ามาก แค่ต่ออุปกรณ์สักตัวเข้ากับเราเตอร์ด้วยสาย แล้วให้อีกตัวใช้งานไร้สาย ก็ช่วยได้พอสมควรแล้ว
    • ถ้ามีไฟล์จำนวนมากและไฟล์เล็กมาก ๆ คอขวดอาจเป็นเพราะ rsync ส่งได้ทีละไฟล์เท่านั้น คุณอาจแบ่งรายชื่อไฟล์ด้วย xargs/parallel แล้วรัน rsync หลายอินสแตนซ์ หรือใช้ตัวอย่าง rclone ที่รองรับ การส่งแบบขนาน ในตัว
    • 6 ชั่วโมงก็ประมาณ 10MB/s ดังนั้นมีโอกาสสูงว่าน่าจะทำได้เร็วกว่านี้มาก อยากรู้ว่าใช้ -z เพื่อบีบอัดหรือไม่ ถ้าใช้อีเธอร์เน็ตได้ บนอุปกรณ์ส่วนใหญ่น่าจะเข้าใกล้ 100MB/s และใช้เวลาราว 35 นาที
    • ถ้าวิธีส่งของ rsync คือ SSH นั่นก็มักเป็นคอขวดได้ OpenSSH เคยมีข้อจำกัดด้านประสิทธิภาพแปลก ๆ มาตามประวัติศาสตร์ และบางครั้งต้องใช้แพตช์ที่ไม่ค่อยมีคนรู้จักเพื่อหลีกเลี่ยงมัน ถ้า CPU ไม่ใช่คอขวด การเปิดการบีบอัดก็ช่วยได้
    • WiFi ใช้ อากาศเป็นสื่อกลาง ร่วมกับอุปกรณ์ไร้สายอื่นทั้งหมด เมื่อมันตรวจพบการชนกันก็จะหยุดแล้วรอเป็นเวลาสุ่ม
      “ในระบบเครือข่ายคอมพิวเตอร์ Carrier-sense multiple access with collision avoidance (CSMA/CA) เป็นวิธีการเข้าถึงสื่อร่วมกันของเครือข่ายที่ใช้การตรวจจับพาหะ แต่จะเริ่มส่งข้อมูลก็ต่อเมื่อพบว่าช่องสัญญาณ ‘ว่าง’ เท่านั้น เพื่อหลีกเลี่ยงการชนกัน เมื่อส่งข้อมูล โหนดจะส่งข้อมูลแพ็กเก็ตทั้งก้อน
      เรื่องนี้สำคัญเป็นพิเศษในเครือข่ายไร้สาย เพราะตัวส่งไร้สายจะทำให้ตัวรับของตัวเองไวต่อสัญญาณลดลงจนใช้งานไม่ได้ระหว่างการส่งแพ็กเก็ต จึงไม่สามารถใช้ CSMA/CD ซึ่งเป็นวิธีตรวจจับการชนกันได้
      CSMA/CA มีความเชื่อถือได้ต่ำเพราะปัญหา hidden node
      CSMA/CA เป็นโปรโตคอลที่ทำงานในชั้น data link”
      https://en.wikipedia.org/wiki/Carrier-sense_multiple_access_...

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

    • ถ้าดิสก์ถูกเข้ารหัสทั้งลูก เว้นแต่จะสั่งให้ LUKS ส่ง TRIM ผ่านได้ วิธีที่ผู้เขียนอธิบายก็จะได้ข้อมูลที่เป็น ข้อมูลสุ่ม แทบทั้งหมดเท่านั้น

  • ใช้ Clonezilla ไปเลยไม่ได้หรือ? มันคัดลอกเฉพาะบล็อกข้อมูลจริงและยังปรับขนาดพาร์ทิชันอัตโนมัติได้ด้วย ฉันทำแบบนั้นตลอด
    แน่นอนว่าโดยปกติฉันจะถอดดิสก์ NVMe ออกจากโน้ตบุ๊กแล้วเอาไปเสียบกับ dock ความเร็วสูง

    • Clonezilla ยอดเยี่ยมมาก มันทำงานอย่างเดียวและส่วนใหญ่ก็สำเร็จตั้งแต่ครั้งแรก สิ่งเดียวที่ฉันบ่นคือช่วงเรียนรู้แรก ๆ ต้องลองปรับอะไรหลายอย่าง
      ฉันยังไม่ไว้ใจมันถึงขั้นปล่อยทิ้งไว้เฉย ๆ ได้ทั้งหมด การสำรองข้อมูลไม่เหมือนกับการรวมการสำรองและการกู้คืนเข้าด้วยกัน ดังนั้นควรทดลองไว้ก่อน และ Clonezilla ก็อาจมีปัญหาได้เวลาสร้างพาร์ทิชันใหม่บนดิสก์ที่แตกต่างจากต้นทางมาก

  • น่าจะหลายสิบปีแล้วที่ฉันไม่ได้ “ติดตั้ง” ระบบปฏิบัติการลงเดสก์ท็อปหรือโน้ตบุ๊กแบบจริงจัง ฉันมักคัดลอกไฟล์แล้วค่อยปรับเฉพาะส่วนที่จำเป็น โดยปกติจะถือโอกาสนี้อัปเดตพารามิเตอร์อย่างชนิดของไฟล์ซิสเต็ม ขนาดบล็อก การเข้ารหัส ฯลฯ ด้วยการสร้างไฟล์ซิสเต็มใหม่แล้วใช้ rsync ย้ายไฟล์
    ถึงอย่างนั้น ถ้าเป็นคนที่วางแผนล่วงหน้า การใช้แนวทางเชิงประกาศมากกว่าอย่าง NixOS ที่คัดลอกแค่การตั้งค่าแล้วติดตั้งส่วนที่เหลือใหม่อัตโนมัติ ก็น่าจะดีกว่า

  • ถ้าเชื่อมต่ออุปกรณ์กันโดยตรงผ่าน WiFi โดยไม่มี AP คั่นกลาง น่าจะเพิ่ม ความเร็วในการรับส่ง ได้เป็นสองเท่า ในสถานการณ์นี้ก็น่าลองทำอยู่