Hyperspace: แอป Mac ที่ช่วยประหยัดพื้นที่ดิสก์โดยไม่ต้องลบไฟล์

 (hypercritical.co)
1 คะแนน โดย GN⁺ 2025-02-26 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • โดยปกติการจัดการไฟล์ซ้ำบน Mac มักตั้งอยู่บนแนวคิดของการลบไฟล์ แต่ Hyperspace ใช้ APFS clone เพื่อให้ไฟล์ที่มีเนื้อหาเดียวกันใช้ข้อมูลร่วมกัน จึงกู้คืนพื้นที่ได้โดยยังคงเก็บไฟล์ไว้
  • copy-on-write clone ของ APFS ทำงานคล้ายคำสั่ง “Duplicate” ใน Finder คือไม่เขียนข้อมูลจริงซ้ำอีกครั้ง แต่แชร์ข้อมูลกับไฟล์ต้นฉบับ ทำให้การคัดลอกไฟล์ขนาดใหญ่เสร็จแทบจะทันที
  • เมื่อนักพัฒนาพบว่าดิสก์ใกล้เต็ม จึงสร้างสคริปต์ Perl เพื่อค้นหาไฟล์ที่มีเนื้อหาเดียวกันแต่ไม่ได้เป็น clone และพบว่าสามารถประหยัดพื้นที่ได้ หลายสิบ GB ก่อนจะพัฒนาต่อเป็นแอป
  • แอปสามารถดาวน์โหลดมาสแกนและตรวจสอบพื้นที่ที่ประหยัดได้ฟรี แต่การกู้คืนพื้นที่จริงต้องมี การชำระเงิน
  • เนื่องจากแอปไปแก้ไขไฟล์ที่ผู้ใช้ไม่ได้สร้างหรือเป็นเจ้าของเอง จึงมีความเสี่ยงสูง แต่ก็อาจช่วยผู้ใช้ Mac จำนวนมากได้อย่างเป็นรูปธรรม

กู้คืนพื้นที่โดยยังคงเก็บไฟล์ไว้ด้วย APFS clone

  • Hyperspace จะตรวจหาไฟล์ที่มีเนื้อหาเดียวกันแต่ ไม่ได้อยู่ในความสัมพันธ์แบบ clone แล้วแปลงให้เป็น APFS clone เพื่อให้ใช้สำเนาข้อมูลบนดิสก์ร่วมกันเพียงชุดเดียว
  • แอปจัดการไฟล์ซ้ำบน Mac แบบเดิม ๆ มักค้นหาไฟล์ซ้ำแล้ว ลบ เพื่อประหยัดพื้นที่ แต่ Hyperspace กู้คืนพื้นที่โดยไม่ต้องลบไฟล์
  • ความสามารถหลักของ APFS มีทั้ง snapshot แบบตามช่วงเวลา และ copy-on-write clone
    • snapshot ถูกใช้เพื่อทำให้การสำรองข้อมูลด้วย Time Machine มีความเสถียรและมีประสิทธิภาพมากขึ้น
    • copy-on-write clone อาศัยโครงสร้างที่ยืดหยุ่นระหว่าง directory entry กับเนื้อหาไฟล์
  • เมื่อคัดลอกไฟล์ใน Finder ด้วยคำสั่ง “Duplicate” เนื้อหาไฟล์จริงจะไม่ถูกคัดลอกซ้ำ แต่จะสร้าง clone file ที่แชร์ข้อมูลกับต้นฉบับ
    • ด้วยโครงสร้างนี้ การคัดลอกใน Finder จึงเสร็จแทบจะทันที ไม่ว่าไฟล์จะมีขนาดเท่าใดก็ตาม

รูปแบบการเปิดตัวและบันทึกด้านการพัฒนา

  • ช่วงปลายปี 2024 เมื่อนักพัฒนาพบว่าดิสก์บน Mac ของตนใกล้เต็ม จึงเขียนสคริปต์ Perl เพื่อค้นหาไฟล์ที่มีเนื้อหาเดียวกันแต่ไม่ใช่ clone แล้วเปลี่ยนให้เป็น clone
    • สคริปต์นี้เรียกใช้เครื่องมือบรรทัดคำสั่งที่เขียนด้วย C และเครื่องมือบรรทัดคำสั่งที่เขียนด้วย Swift
    • เมื่อรันแล้วพบว่าสามารถประหยัดพื้นที่ได้ หลายสิบ GB และต่อมาจึงพัฒนาเป็นแอป Mac
  • Hyperspace ให้บริการบน Mac App Store
  • ในแง่การพัฒนา Hyperspace เป็นแอป Mac ที่สร้างด้วย SwiftUI ตัวที่สองของนักพัฒนา และเป็นแอปแรกที่ใช้ SwiftUI life cycle
    • นอกจากนี้ยังเป็นแอปที่สองที่ใช้ Swift 6
    • การใช้ Swift 6 ตั้งแต่ช่วงเริ่มต้นพัฒนาง่ายกว่าการแปลงแอปที่เปิดตัวไปแล้วให้เป็น Swift 6 มาก
    • Swift 6 ยังมีจุดที่ไม่เรียบร้อยอยู่มาก และคาดหวังว่าจะได้รับการปรับปรุงต่อไปในอนาคต
  • Hyperspace แก้ไขไฟล์ที่แอปไม่ได้สร้างขึ้นเองและไม่ได้เป็นเจ้าของ เช่นเดียวกับกระบวนการแปลงจาก HFS+ ไปเป็น APFS
    • นักพัฒนาเรียกมันว่าเป็น แอปที่เสี่ยงที่สุด ที่ตนเคยสร้าง
    • แต่ในขณะเดียวกันก็อาจเป็นแอปที่มีประโยชน์ต่อผู้คนจำนวนมากที่สุดด้วย

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

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

 
GN⁺ 2025-02-26
ความคิดเห็นบน Hacker News

  • ก่อนหน้านี้เคยทำยูทิลิตีบรรทัดคำสั่ง dedup ที่ทำงานแบบเดียวกันไว้
    มีโหมด dry run, เลือกต้นฉบับสำหรับ clone ที่เหมาะที่สุดแบบ “ฉลาด”, เข้าใจ hard link และ clone อื่น ๆ, เก็บรักษา metadata และจัดการไฟล์บีบอัด HFS ได้อย่างถูกต้องด้วย
    ข้อมูลของผมยังไม่เคยพัง แต่ก็เหมือนเครื่องมือระบบไฟล์ทั่วไป ใช้งานโดยรับความเสี่ยงเอง
    0 - https://github.com/ttkb-oss/dedup

    • เท่าที่ลองแค่สแกนและยังไม่ได้ deduplicate จริง ๆ สำหรับ workspace 7.6GB ที่มี disk image, program binary และ intermediate representation ก็เห็นความต่างพอสมควร
      โดยค่าเริ่มต้น Hyperspace ไม่ได้สแกนทุกไฟล์ แต่ดูเฉพาะไฟล์ที่อยู่ใน allowlist และดูเหมือนมีโครงสร้างที่ต้องเข้าใจเนื้อหาไฟล์ จากมุมผู้ใช้ปลายทาง ผมไม่รู้ว่าแยกความแตกต่างระหว่างไฟล์ Text กับไฟล์ Source Code อย่างไร และการสแกนค่าเริ่มต้นพบเพียง 360MB ที่เป็นเป้าหมายสำหรับการ deduplicate แต่เมื่ออนุญาตทุกไฟล์ก็เพิ่มเป็น 842MB
      โดยค่าเริ่มต้น ไฟล์ที่เล็กกว่า 100KB ก็ไม่ถูกสแกนเช่นกัน และเมื่อปิดข้อจำกัดขนาดพร้อมอนุญาตทุกไฟล์ ก็เพิ่มเป็น 1.1GB ภายใต้เงื่อนไขทุกไฟล์และไม่มีข้อจำกัดขนาด Hyperspace สแกน 67,309 ไฟล์จากทั้งหมด 68,874 ไฟล์ ส่วน dedup สแกน 67,426 ไฟล์
      Hyperspace บอกว่ามีไฟล์ 29,522 ไฟล์ที่สามารถ deduplicate ได้ ส่วน dedup พบ 29,447 ไฟล์ มีความต่างอยู่หนึ่งไฟล์เพราะมีไฟล์ที่ deduplicate ไปแล้ว 76 ไฟล์ แต่ไม่รู้สาเหตุที่แน่ชัด
      เวลาสแกน Hyperspace ใช้ประมาณ 50 วินาที ส่วน dedup ใช้ 14 วินาที ดูเหมือน Hyperspace จะสแกนระบบไฟล์ก่อน แล้วคำนวณรายการซ้ำ จากนั้นจึง deduplicate แต่ไม่รู้ว่าทำไมสองขั้นตอนแรกถึงไม่ทำไปพร้อมกัน ผมให้ใส่ metadata ของระบบไฟล์ลงคิวระหว่างสแกนแล้วเริ่มคำนวณรายการซ้ำแบบขนาน และส่วนใหญ่สามารถกรองสิ่งที่ไม่ตรงกันออกได้ด้วยข้อมูลขนาดที่ได้มา “ฟรี ๆ” ตอนเดินไดเรกทอรีด้วย fts_read
      Hyperspace บอกว่าประหยัดได้ 1.1GB ส่วน dedup พบ 1.04GB และอีก 882MB ที่ประหยัดไปแล้ว ผมไม่มีแผนจะซื้อ Hyperspace จึงไม่รู้เวลาการ deduplicate จริง หรือการเก็บรักษา metadata และการจัดการไฟล์แปลก ๆ แต่ dedup ใช้เวลารวมสแกนและ deduplicate 31 วินาที
      แม้หลังจาก deduplicate ด้วย dedup แล้ว Hyperscan ยังมองว่ายังมีไฟล์ 2 ไฟล์ที่ deduplicate ได้ Hyperspace ก็ดูเหมือนจะจัดการไฟล์ที่มี hard link หลายอัน, ไฟล์ว่าง และข้อยกเว้นหลายอย่างที่ dedup ตรวจสอบด้วย ส่วนการเก็บรักษา ACL หรือ attribute อื่น ๆ ทดสอบไม่ได้ถ้าไม่จ่ายเงิน แต่ดูจาก strings แล้วน่าจะจัดการอยู่ และ HFS compression เป็น edge case ที่ยุ่งยาก จึงยังยืนยันไม่ได้ว่าการสแกนของ Hyperspace จัดการอย่างไร
    • ลองรันกับที่ที่มีไฟล์เกือบเหมือนกันจำนวนมาก เช่นไดเรกทอรีพัฒนา Postgres แล้วประหยัดได้ ประมาณ 1.7GB
      โปรเจกต์ไม่มีไลเซนส์ ดังนั้นถ้าเป็นไปได้อยากให้ใส่ไลเซนส์ที่ต้องการไว้ด้วย ผมทำ pull request เพื่อปรับปรุงขั้นตอนติดตั้งเล็กน้อยไว้ด้วย: https://github.com/ttkb-oss/dedup/pull/6
    • เพิ่งลองใช้เมื่อกี้ ทำงานได้ดี พอได้เห็นจริง ๆ ว่ามีไฟล์ซ้ำในไฟล์บางประเภทมากแค่ไหน โดยเฉพาะใน node_modules ถึงได้ตระหนักถึงศักยภาพของเทคนิคนี้
      แค่ดูบาง subdirectory ก็ไม่ใช่เรื่องแปลกที่จะเปลี่ยนสำเนาไฟล์ JS 50 ชุดให้เหลือชุดเดียว แต่เพราะยังเป็น “pre-release” และดาวบน GitHub ก็ยังค่อนข้างน้อย เครื่องมือแบบนี้ถ้ามีบั๊กจะน่ากลัวพอสมควร เลยสงสัยเรื่องความเสถียร
    • เอกสารยอดเยี่ยม และที่ make เสร็จแทบจะทันที ก็น่าประทับใจด้วย
    • ถ้าต้องการรายการทางเลือก ดูคอมเมนต์ใน https://news.ycombinator.com/item?id=38113396 ได้
      เมื่อก่อนเคยใช้ https://github.com/sahib/rmlint และก็ไม่ได้มีอะไรให้บ่นเป็นพิเศษ

  • เมื่ออ่านส่วนที่ว่า “Hyperspace ไม่มีวิธีประสานกับแอปอื่น ๆ ทั้งหมดหรือกับ macOS เอง เพื่อกำหนดจังหวะที่ปลอดภัยสำหรับการแทนที่ไฟล์ และไม่มีวิธีบังคับควบคุมไฟล์นั้นแบบเอกสิทธิ์” ก็ทำให้นึกสงสัยว่าทำไมตัวระบบไฟล์เองถึงไม่รัน กระบวนการกำจัดข้อมูลซ้ำ ลักษณะคล้ายกันในแบ็กกราวด์
    ถ้าเป็นชั้น abstraction ระดับนั้นก็น่าจะจัดการปัญหาความปลอดภัยแบบนี้ได้ เลยสงสัยว่าถ้าให้เกิดขึ้นอัตโนมัติภายใน APFS จะมีข้อเสียอะไรบ้าง

    • ใน ZFS จะ ใช้ RAM มาก ดูเหมือนเพราะ ZFS ทำงานในระดับบล็อก จึงต้องติดตามบล็อกจำนวนมากไว้เปรียบเทียบเมื่อมีการเขียนบล็อกใหม่
      ถ้าทำในระดับไฟล์ก็อาจใช้ทรัพยากรน้อยลงได้ แต่ไม่แน่ใจว่าการ implement จะง่ายขึ้นหรือซับซ้อนขึ้น อีกอย่าง ถ้าแก้แค่ 1 ไบต์ในไฟล์ขนาดใหญ่ ระบบไฟล์ก็ต้องทำสำเนาไฟล์นั้นใหม่อีกครั้ง ทำให้เกิดกิจกรรมบนดิสก์มาก ซึ่งอาจไม่ใช่เรื่องที่เข้าใจได้โดยสัญชาตญาณ
    • ในอุปกรณ์จัดเก็บข้อมูลแบบบล็อก มักทำเรื่องนี้ร่วมกับการบีบอัด แน่นอนว่าถ้าระบบไฟล์ เข้ารหัส บล็อกก่อนส่งไปยังอุปกรณ์ก็จะล้มเหลว
      การกำจัดข้อมูลซ้ำที่ชั้นนี้ดีตรงที่ทำได้ข้ามหลายระบบไฟล์ ตัวอย่างเช่น ถ้ามีระบบหนึ่งพันเครื่องที่มีไฟล์ระบบปฏิบัติการเดียวกัน ก็ประหยัดพื้นที่จัดเก็บได้มหาศาล และความแตกต่างมักมีแค่การตั้งค่าเฉพาะเครื่องอย่าง host key หรือ hostname ระบบไฟล์เดี่ยว ๆ จะมองไม่เห็นความเหมือนร่วมกันแบบนี้
      แต่จะมีปัญหาถ้าการกำจัดข้อมูลซ้ำทำให้จำนวนสำเนาของไฟล์ที่มีการใช้งานหนักลดลง ในตัวอย่างข้างต้น ถ้าบูตหนึ่งพันเครื่องพร้อมกัน อิมเมจเคอร์เนลอาจเจอโหลด I/O มหาศาล
    • บน Linux นี่คือ API สำหรับกำจัดข้อมูลซ้ำ มาตรฐานที่ใช้ใน btrfs และ XFS
      เมื่อขอให้ระบบปฏิบัติการช่วยกำจัดข้อมูลซ้ำให้กับชุดช่วงที่กำหนดอย่างสุภาพ OS จะล็อกช่วงเหล่านั้น ตรวจสอบว่าข้อมูลเหมือนกันจริง แล้วจึงทำการกำจัดข้อมูลซ้ำให้ และยังส่งกลับเป็นฟิลด์ด้วยว่าในแต่ละช่วงกำจัดซ้ำไปได้กี่ไบต์ ดังนั้นโปรแกรมใน user space จึงไม่มีทางทำไฟล์พังได้
    • ZFS ทำเรื่องนี้จริง ๆ: https://www.truenas.com/docs/references/zfsdeduplication/
    • Windows Server ก็มีฟีเจอร์นี้บนโวลุ่ม NTFS และ ReFS
      เคยใช้ค่อนข้างมากบน ReFS ที่รัน Hyper-V VM และผลลัพธ์ยอดเยี่ยมมาก ตอนนั้น VM ส่วนใหญ่เป็น Windows Server 2016/2019 ปนกัน ทำให้ลดการใช้พื้นที่จัดเก็บได้ประมาณ 45%

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

    • เคยอธิบายโมเดลนี้ไว้ในพอดแคสต์ ผู้ใช้จำนวนมากจะซื้อสิ่งนี้มา รันครั้งเดียว ประหยัดได้ไม่กี่ GB แล้วก็จบ ดังนั้นการสมัครสมาชิกจึงไม่ค่อยสมเหตุสมผล
      ยังไงในหนึ่งเดือนเราจะเผลอสร้างไฟล์ซ้ำที่เหมือนกันเป๊ะ ๆ ได้มากแค่ไหนกัน?
      จริง ๆ ก็มีตัวเลือกสมัครสมาชิกหรือซื้อถาวรสำหรับคนที่จะใช้บ่อย แต่สำหรับหลายคน การซื้อในแอปแบบครั้งเดียว ที่ใช้ได้ในช่วงเวลาจำกัดนั้นค่อนข้างสมเหตุสมผล และยังสามารถรันฟรีซ้ำเมื่อไรก็ได้ เพื่อตรวจดูว่าสะสมพอให้จ่ายเงินอีกครั้งหรือยัง
    • คุณค่าของแอปกำจัดไฟล์ซ้ำแบบนี้ สำหรับผมอยู่ที่ การไม่เหลือไฟล์ซ้ำค้างไว้ มากกว่าการประหยัดพื้นที่
      ผมไม่ได้สร้างปริมาณมหาศาล แต่บางครั้งก็มีไฟล์ซ้ำขนาดใหญ่เกิดขึ้นเมื่อรวมบางส่วนหรือทั้งหมดเข้าด้วยกัน มักเกิดในสถานการณ์ประหลาด ๆ เช่น ต้องจับคู่ผลลัพธ์จากการกู้คืนฮาร์ดไดรฟ์กับไฟล์ในอีกตำแหน่งหนึ่ง หรือต้องจัดระเบียบโฟลเดอร์ Downloads ที่รกให้เข้ากับปลายทางที่เป็นระเบียบ
      เช่น เคยมีกรณีที่แบ็กอัป Time Machine ดันเวอร์ชันเก่าของไฟล์ที่ผมไม่รู้ด้วยซ้ำว่ามีบันทึกอยู่ และคิดว่าหายไปนานแล้วออกมา แต่ทำชื่อไดเรกทอรีพัง และทำให้เนื้อหาพรางอ่านยากไปบางส่วน มีไดเรกทอรีชื่อเป็นตัวเลขอยู่หลายพันอัน ข้างในอาจมีไฟล์ที่อยากเก็บ แต่ก็ไม่รู้เลยว่ามีอยู่แล้วหรืออยู่ที่ไหน เพราะไม่มีโครงสร้างให้ดูเข้าใจได้ ในทางกลับกัน หลายครั้งก็มีแค่ไฟล์ข้อความของระบบ build เดียวกันอยู่ไฟล์เดียว แบบนั้นก็ทิ้งได้แน่นอน
    • พอจำได้ว่าเมื่อ 10 ปีก่อนซอฟต์แวร์ส่วนใหญ่ก็เป็นแบบนี้ เลยสงสัยว่าตัวเองแก่ขนาดนั้นแล้วหรือ
      หรือผู้คนคุ้นชินกับกับดัก subscription มากเกินไป จนรู้สึกว่านี่เป็นโมเดลใหม่
    • ผมชอบ โมเดลราคา นี้มากจริง ๆ
      ถ้าซอฟต์แวร์อื่นทำแบบนี้ได้ง่ายก็คงดี แต่ส่วนใหญ่ learning curve จะขวางไว้จนกว่าจะเห็นคุณค่า
    • สดใหม่กว่าการ “ทดลองใช้ฟรี” ที่ต้องจำไปกดยกเลิกเยอะ
      แนะนำว่าถ้าเป็น trial แบบนั้น ให้ใช้บัตรเสมือนที่ล็อกได้ พอเผลอลืมยกเลิก การตัดเงินก็จะถูกบล็อกไว้ แต่ก็สงสัยว่ามีใครหาเจอไหมว่าราคาไลเซนส์จริงบนเว็บไซต์คือเท่าไร

  • สงสัยว่าแอปใช้อัลกอริทึมแบบไหนในการดูว่าไฟล์สองไฟล์เหมือนกันหรือไม่
    มีวิธีที่น่าสนใจหลายแบบ เช่น hash, การเปรียบเทียบระดับบิต ฯลฯ แต่แต่ละแบบก็มีข้อเสียของตัวเอง ถ้ามีไฟล์จำนวนมาก วิธีไหนดีที่สุด

    • ไม่รู้ว่า Siracusa ทำอะไรแน่ แต่พอเดาได้
      สำหรับไฟล์ผู้สมัครแต่ละไฟล์ ต้องมี “คีย์” เพื่อเช็กว่าเหมือนกับไฟล์ผู้สมัครอื่นหรือไม่ ไฟล์อาจมีเป็นล้าน ๆ ไฟล์ ดังนั้นคีย์ต้องเล็กและสร้างได้เร็ว แต่ในขณะเดียวกันก็ต้องไม่มี false positive
      คำตอบที่ obvious ในยุคนี้คือ SHA256 hash ของเนื้อหาไฟล์ มันเร็วมาก ขนาดก็แค่ 32 ไบต์ซึ่งไม่ใหญ่มาก และโอกาสเกิด false positive หรือ collision ก็ต่ำจนโลกคงแตกก่อนที่จะได้เจอจริง ๆ SHA256 เป็นมาตรฐานโดยพฤตินัยสำหรับงานแบบนี้ ถ้าใช้วิธีอื่นก็คงน่าประหลาดใจทีเดียว
    • นึกถึง https://en.wikipedia.org/wiki/Venti_(software)
      มันเป็น ระบบไฟล์แบบระบุที่อยู่ด้วยเนื้อหา ที่ใช้ hash สำหรับกำจัดข้อมูลซ้ำ และเพราะคำนวณ hash ตอนเขียน ต้นทุนด้านประสิทธิภาพจึงถูกกระจายออกไป
    • ผมคง hash 1024 ไบต์แรกของทุกไฟล์ แล้วค่อยไปต่อเฉพาะเมื่อมี collision
      แบบนั้นก็ไม่ต้อง hash ไฟล์ใหญ่ทั้งไฟล์ และดูเพิ่มเฉพาะไฟล์ที่มี hash เดียวกันเท่านั้น

  • Apple มี คำสั่ง cp ที่ปรับแก้แล้วมาพร้อมระบบ ซึ่งรองรับแฟล็ก -c เพื่อให้ใช้ฟีเจอร์ clone ของ APFS ได้

    • ถ้า cp ที่ใช้อยู่ไม่รองรับสิ่งนั้น ก็เรียกผ่าน Python ได้เช่นกัน
      เช่น import Foundation; Foundation.NSFileManager.defaultManager().copyItemAtPath_toPath_error_(...) ประมาณนี้

  • ไฟล์ A อยู่สองตำแหน่ง และหลังจากรันสิ่งนี้แล้ว ถ้าแก้ไข A_0 ก็สงสัยว่า A_1 จะเปลี่ยนตามไปด้วยหรือไม่ หรือมีแค่สถานะใหม่ของ A_0 ที่ถูกทำให้เป็นไฟล์จริง ส่วน A_1 ยังอยู่เหมือนเดิม

    • มีเหตุผลที่เรียกว่า copy-on-write (คัดลอกเมื่อเขียน)
      ถ้าแก้ไข A_0 ระบบจะสร้างสำเนาของไฟล์นั้น ณ ตอนที่มีการเขียน และจะไม่แตะ A_1
      https://en.wikipedia.org/wiki/Copy-on-write#In_computer_stor...
    • เป็นการใช้ฟีเจอร์ copy-on-write ของระบบไฟล์
      ดังนั้น A_1 จะถูกปล่อยไว้เหมือนเดิม และจะสร้างสำเนาใหม่สำหรับส่วนที่แก้ไขของ A_0 ดูรายละเอียดได้ที่ https://developer.apple.com/documentation/foundation/file_sy...

  • จุดที่สะดุดตาคือ ก่อนที่ Apple จะประกาศ APFS ที่ WWDC 2017 นั้น มีการแอบทดลองแปลง iPhone ทุกเครื่องเป็น APFS ในส่วนหนึ่งของอัปเดต iOS 10.x แล้วแปลงกลับเป็น HFS+
    สงสัยว่าถ้าเกิดการเปลี่ยนระบบไฟล์ผิดพลาดจะย้อนกลับได้อย่างไร โค้ดอาจตรวจสอบได้ละเอียดพอ แต่ถ้ามีปัญหาอะไรขึ้นมา ดูเหมือนจะถอนกลับไม่ได้

    • ถ้าจำไม่ผิด การย้ายจาก HFS+ ไป APFS ทำได้โดยไม่ต้องแตะ data block และจะเขียน metadata block กับ superblock ของ APFS ลงดิสก์แบบขนาน
      ในการทดสอบ migration ของ Apple จะทำการย้ายทั้งหมด รวมถึงการสร้าง superblock ของ APFS แต่หยุดไว้ก่อนถึง commit ที่จะแทนที่ superblock ของ HFS+ ด้วย superblock ของ APFS อย่างถาวร ตอนย้อนกลับก็แค่ “เก็บกวาด” superblock และ metadata block ของ APFS ที่สร้างไว้เท่านั้น
    • ไปดูช่วงนั้นของการนำเสนอแล้ว [0] แต่แทบไม่มีรายละเอียด นอกจากบอกว่าทำเพื่อทดสอบความสอดคล้อง
      ในฐานะคนที่เคยทำหลายอย่างพังในสภาพแวดล้อมจริงมาแล้ว ถ้ามีคนบอกให้รัน migration ใหญ่ขนาดนี้ ก็ไม่แน่ใจว่าจะกล้ากดปุ่มไหม
      [0] https://www.youtube.com/watch?v=IcyaadNy9Jk&t=1670s
    • ดูเหมือนจะจินตนาการน้อยไปหน่อยนะ นี่ไม่ใช่เทคโนโลยีระดับอัญมณีมงกุฎที่มีแต่ Apple เท่านั้นที่ทำได้
      ในโลกโอเพนซอร์สก็มีเครื่องมือแปลงระบบไฟล์ ext เป็น btrfs อยู่ และ (1) ย้อนกลับได้ รวมถึง (2) ระหว่างใช้ระบบไฟล์ btrfs ก็ยัง mount ระบบไฟล์ ext เดิมได้ด้วย

  • เริ่มจากเล่าเรื่อง แล้วค่อยบีบให้แคบลงเป็นปัญหา จากนั้นแสดงให้เห็นว่าโซลูชันแก้ปัญหานั้นได้ราวกับเวทมนตร์
    เป็นตัวอย่างที่ดีมากของ การตลาดที่ยอดเยี่ยม

  • ลองรันกับโฟลเดอร์โปรเจกต์ NodeJS ขนาดใหญ่แล้ว แต่บอกว่าประหยัดได้แค่ 1GB จากโฟลเดอร์ 8.1GB
    ลองรันอีกครั้งโดยรวมโฟลเดอร์ home ของผู้ใช้ด้วย ผลคือจากไฟล์ 731K ไฟล์, โฟลเดอร์ 127K โฟลเดอร์ และไฟล์เป้าหมาย 2,755 ไฟล์ ประหยัดได้รวมเพียง 1.3GB เพิ่มจากตอนรันเฉพาะโฟลเดอร์ NodeJS แค่ราว 300MB
    พยายามสแกน System กับ Library ด้วย แต่ถูกปฏิเสธเพราะปัญหาสิทธิ์ ดูเหมือนเพราะใช้ pnpm เป็น package manager อยู่แล้ว การใช้ดิสก์จึงแทบจะเหมาะสมที่สุดอยู่แล้ว
    ไอเดียน่าสนใจ แต่ด้วยราคาปัจจุบันยังหาเหตุผลมารองรับได้ยาก และคงจะดีถ้าเป็น background process ที่รันเดือนละครั้งประมาณนั้น

    • ถ้าได้ 1GB จาก 8.1GB ก็แปลว่า 12% ของพื้นที่ที่ใช้ไปกำลังสูญเปล่า อยู่ไม่ใช่เหรอ? ไม่แน่ใจว่าอ่านถูกไหม
    • pnpm ตั้งใจให้เป็นตัวแทนแบบ drop-in ของ npm และทำ deduplication ให้อัตโนมัติ
    • macOS มี sealed volume อยู่ จึงเห็นข้อผิดพลาดเรื่องสิทธิ์ใน System กับ Library
      https://support.apple.com/guide/security/signed-system-volum...
    • ยังไม่มีเวลาลองเอง แต่ในสกรีนช็อตของ App Store เห็นชัดว่ามี ตัวเลือกขนาดไฟล์ขั้นต่ำ สำหรับพิจารณา
      น่าจะใส่มาเพื่อลด comparison buffer แต่ก็เป็นไปได้ว่าไฟล์ใน node_modules มีขนาดต่ำกว่านี้เลยไม่ถูกนำมาพิจารณา
    • ไม่รู้ว่าราคาเท่าไร ดูเหมือนไม่ได้เปิดเผยไว้ที่ไหนเลย

  • เคยทำสคริปต์ที่คล้ายกันแต่เรียบง่ายกว่า ซึ่งเปลี่ยนไฟล์ที่มีเนื้อหาเหมือนกันให้เป็น hard link
    แรงจูงใจหลักคือแพ็กเกจใน Python virtual environment มักมีการติดตั้งแพ็กเกจคล้าย ๆ กันไว้ และแม้เวอร์ชันต่างกัน ไฟล์จำนวนมากก็ยังตรงกันอยู่ แพ็กเกจบางตัวอย่าง Numpy, PyTorch, TensorFlow ค่อนข้างใหญ่ จึงประหยัดพื้นที่ดิสก์ได้พอสมควร
    https://github.com/albertz/system-tools/blob/master/bin/merg...

    • อันนี้ไม่ได้ใช้ hard link หรือ symbolic link แต่ใช้ฟีเจอร์ของระบบไฟล์ในการสร้าง copy-on-write clone [1]
      [1] https://en.wikipedia.org/wiki/Apple_File_System#Clones
    • uv ทำแบบนี้เป็นค่าเริ่มต้น
      เครื่องมืออื่นอย่าง poetry, hatch, pdm ก็น่าจะทำเหมือนกัน แต่ไม่ค่อยแน่ใจรายละเอียดการทำงานเพราะใช้น้อยกว่า