ดิสก์ที่เต็มจนไม่สามารถกู้คืนได้

 (sixcolors.com)
2 คะแนน โดย GN⁺ 2024-04-05 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • โวลุ่มเริ่มต้นระบบของ M2 MacBook Pro เต็มระหว่างดาวน์โหลดเกมจาก Steam จนเหลือพื้นที่เพียง 41KB ทำให้ macOS ตกอยู่ในสภาพที่แม้แต่การลบไฟล์ก็ทำไม่ได้
  • ทั้งการล้างถังขยะใน Finder, คำสั่ง rm และ find -exec rm ใน Terminal รวมถึงการ ลบสแนปช็อต Time Machine ใน Disk Utility ล้วนล้มเหลวด้วยข้อผิดพลาดในกลุ่ม “No space left on device”
  • หลังรีสตาร์ต เครื่องก็บูตค้างกลางทาง และแม้จะใช้ recoveryOS กับฟีเจอร์ Share Disk ของ Apple silicon เพื่อเมานต์บน Mac อีกเครื่อง ก็ยังบังคับลบไม่ได้
  • หลังล้างไดรฟ์และติดตั้ง macOS ใหม่แล้วพยายามกู้คืนจาก Time Machine ก็เจอปัญหาต่อเนื่อง ทั้งการกู้คืน Ventura ค้าง, ความต่างของเวอร์ชันระหว่าง Sonoma 14.4 กับ 14.3.1 เดิม และการเมานต์เครือข่าย SMB/Samba ล้มเหลว
  • สุดท้ายจึงคัดลอกอิมเมจดิสก์ Time Machine ล่าสุดไปยัง SSD ภายนอก 1TB แล้วกู้ไฟล์ในโฮมไดเรกทอรีและแอปด้วยตนเอง แสดงให้เห็นว่าเมื่อพื้นที่จัดเก็บหมดชนกับการกู้คืนแบ็กอัพที่ล้มเหลว แม้แต่ผู้ใช้ชำนาญก็รับมือได้ยาก

Mac ที่พื้นที่จัดเก็บหมดจนลบไฟล์ไม่ได้

  • พื้นที่จัดเก็บของ M2 MacBook Pro เต็มระหว่างดาวน์โหลดเกมที่ซื้ออย่างถูกต้องจาก Steam
  • แม้ไดรฟ์จะเต็มอย่างน่ากังวล macOS ก็ไม่ได้หยุดการดาวน์โหลดไฟล์ขนาดใหญ่จาก Steam และบนโวลุ่มเริ่มต้นระบบเหลือพื้นที่เพียง 41KB
  • ไฟล์สำคัญส่วนใหญ่อยู่บนคลาวด์ และไม่ได้อยู่ในสถานการณ์ที่จำเป็นต้องรักษาไฟล์ขนาดใหญ่ในเครื่องไว้
  • ปัญหาไม่ใช่แค่พื้นที่ไม่พอธรรมดา แต่เป็นสภาพที่ระบบปฏิบัติการไม่สามารถลบไฟล์ด้วยวิธีใด ๆ ได้เลย

สาเหตุที่สงสัย: การดาวน์โหลดของ Steam และสแนปช็อต Time Machine ในเครื่อง

  • เป็นไปได้ว่า macOS ควบคุมการเพิ่มขึ้นของการใช้พื้นที่ไม่ทัน เพราะมีการเชื่อมต่ออินเทอร์เน็ตระดับกิกะบิตและไฟล์ Steam ขนาดใหญ่
  • ขณะเดียวกัน จุดที่น่าสงสัยคือ macOS กำลังสร้าง สแนปช็อต Time Machine ในเครื่อง อยู่ด้วย
  • macOS จะเก็บสแนปช็อตไว้เพื่อให้มีแบ็กอัพในเครื่องสำหรับ 24 ชั่วโมงล่าสุด แม้กำลังแบ็กอัพไปยังปลายทาง Time Machine ภายนอกหรือบนเครือข่ายก็ตาม
  • ไฟล์ของ Steam ภายนอกดูเหมือนเป็นไฟล์ขนาดยักษ์ไฟล์เดียว แต่จากมุมมองของ Time Machine อาจถูกจัดการต่างออกไป
  • ไฟล์จริงในเครื่องกับสแนปช็อตที่สร้างขึ้นในลักษณะพิเศษอาจชนกัน แต่ยังไม่สามารถยืนยันสาเหตุที่แน่ชัดได้

ความพยายามลบทั้งหมดล้มเหลว

  • การล้างถังขยะใน Finder ล้มเหลวเมื่อใช้ File > Empty Trash
    • ข้อความข้อผิดพลาดคือ “The operation can’t be completed because the disk is full”
  • Terminal เปิดได้ แต่คำสั่ง Unix มาตรฐานอย่าง rm ไม่ทำงาน
    • ข้อความข้อผิดพลาดคือ “No space left on device”
    • ทางเลือกที่ใช้ find เพื่อค้นหาไฟล์ใหญ่แล้วรัน rm ด้วยตัวเลือก -exec ก็ล้มเหลวเช่นกัน
  • ใน Disk Utility ก็พยายามเลือกและลบสแนปช็อต Time Machine ของโวลุ่มเริ่มต้นระบบ APFS แต่ติดข้อจำกัดเดียวกัน
    • โดยทั่วไป สแนปช็อตจะใช้พื้นที่จัดเก็บเฉพาะส่วนต่างจากสแนปช็อตก่อนหน้าเท่านั้น
    • ในกรณีนี้ก็เกิดข้อผิดพลาด “no space left” เช่นกัน

รีสตาร์ต, recoveryOS และ Share Disk ก็ไม่ได้ผล

  • รีสตาร์ตโดยคาดหวังว่าจะล้างแคชได้ แต่หลังจากนั้น Mac ไม่สามารถบูตตามปกติได้อีก
  • เครื่องค้างซ้ำ ๆ หลังแถบความคืบหน้าไปได้ราวครึ่งหนึ่ง
  • ใน recoveryOS ขณะที่โวลุ่มเริ่มต้นระบบไม่ได้ถูกเมานต์ ได้พยายามซ่อมด้วย Disk Utility และทำงานที่เกี่ยวกับการติดตั้งใหม่ แต่คำสั่ง Terminal ยังให้ข้อผิดพลาดเดิม
  • พยายามใช้ฟีเจอร์ Share Disk ของ Apple silicon เพื่อเมานต์ไดรฟ์นั้นบน Mac อีกเครื่อง
    • พยายามบังคับลบผ่านการแชร์ดิสก์ที่ใช้ Samba แต่ล้มเหลว

อุปสรรคต่อเนื่องระหว่างกู้คืน Time Machine

  • มีแบ็กอัพ Time Machine ซึ่งรวมถึงแบ็กอัพจากเย็นวันก่อน และข้อมูลสำคัญส่วนใหญ่อยู่บนคลาวด์ จึงไม่ได้ยึดติดกับการกู้คืนแบบสมบูรณ์มากนัก
  • ขั้นแรก ล้างไดรฟ์แล้วติดตั้ง Ventura ใหม่ผ่าน macOS Recovery ซึ่งเป็นระบบพื้นฐานตอนออกจากโรงงานของ MacBook Pro เครื่องนี้
  • เมื่อเริ่ม macOS ใช้ Migration Assistant เข้าถึงแบ็กอัพ Time Machine บนเครือข่าย และยกเลิกบางรายการที่จะกู้คืนเพื่อให้เหลือพื้นที่จัดเก็บเพียงพอ
  • ระหว่างการกู้คืน Ventura ค้างกลางทางและหลังจากนั้นก็ไม่กลับมาทำงานต่อ
  • ต่อมาจึงอัปเกรด Mac เป็น Sonoma ซึ่งเป็น macOS ที่ใช้อยู่ในตอนนั้น
    • การอัปเกรดสำเร็จ แต่เวอร์ชันที่ติดตั้งคือ 14.4
    • Mac เดิมติดตั้ง 14.3.1 อยู่
    • เมื่อพยายามกู้คืนโดยตรงในขั้นตอนเริ่มต้น ระบบไม่อนุญาตเพราะเวอร์ชันต่างกัน

ปัญหาการเมานต์ Time Machine บนเครือข่ายใน Sonoma 14.4

  • หลังสร้างบัญชีผู้ใช้ Sonoma พื้นฐานแล้ว จึงรัน Migration Assistant
  • Migration Assistant พบและรู้จัก Mac บนเครือข่ายที่จัดการแบ็กอัพ Time Machine
  • แต่ไม่สามารถเมานต์โวลุ่มแบ็กอัพของบุตรได้ และแสดง “Mount failed” ซ้ำ ๆ
  • จากการค้นหาในฟอรัม พบว่าขั้นตอนเมานต์เครือข่ายที่ใช้ SMB/Samba ใน Sonoma เสียสำหรับการกู้คืน Time Machine และยังไม่พบวิธีแก้
  • ปัญหานี้ดูเหมือนยังคงเกี่ยวข้องกับ macOS 14.4 ด้วย

การกู้คืนสุดท้าย: คัดลอกแบ็กอัพไปยัง SSD ภายนอกแล้วโอนย้ายด้วยตนเอง

  • เลิกพยายามกู้คืนเต็มรูปแบบด้วย Migration Assistant และกู้เฉพาะแอปกับไฟล์ที่จำเป็นด้วยตนเอง
  • บน Mac ที่จัดการแบ็กอัพเครือข่าย ดับเบิลคลิกอิมเมจดิสก์ของคอมพิวเตอร์เครื่องนั้น แล้วใส่รหัสผ่านของโวลุ่ม Time Machine
    • โวลุ่ม Time Machine บนเครือข่ายถูกตั้งรหัสผ่านแยกไว้เสมอ
  • หาไอคอนดิสก์ที่มี timestamp ล่าสุด แล้วคัดลอกไปยัง SSD ภายนอก 1TB ที่ว่างอยู่
  • เชื่อมต่อ SSD ภายนอกกับบัญชีชั่วคราวบน MacBook Pro แล้วโอนไฟล์ที่จำเป็น
    • รวมเนื้อหาส่วนใหญ่ของโฟลเดอร์โฮมไดเรกทอรี
    • ยกเว้นไฟล์ดาวน์โหลดขนาดใหญ่และไฟล์วิดีโอบางส่วนที่ไม่จำเป็น
  • ตั้งใจเก็บ SSD ภายนอกไว้สักระยะ เพื่อใช้กู้เพิ่มเติมหากพบไฟล์ที่ขาดหาย

ทางเลือกที่ไม่ได้ลอง

  • สามารถ unmount ไดรฟ์ Time Machine สำหรับแบ็กอัพเครือข่ายจาก Mac ที่จัดการแบ็กอัพ แล้วเชื่อมต่อโดยตรงกับ Mac ของบุตรได้
    • ในกรณีนั้น ไดรฟ์อาจปรากฏเป็นจุดเริ่มต้นใน Migration Assistant
  • อาจคัดลอกดิสก์เสมือนจากอิมเมจดิสก์ Time Machine ที่เมานต์อยู่ เพื่อให้ SSD ภายนอก 1TB ดูเหมือนโวลุ่มต้นทางของ Mac ได้
    • ยังไม่ได้ตรวจสอบว่าวิธีนี้จะใช้ได้จริงหรือไม่
    • หากสำเร็จ ก็อาจกู้คืนโดยตรงด้วย Migration Assistant ได้
  • งานหลายชั่วโมงและความพยายามเกินหนึ่งวันสะสมไปแล้ว และผู้ใช้ไม่ได้ต้องการการกู้คืนแบบครบถ้วนระดับไดเรกทอรีมากนัก จึงไม่ได้ทดลองเพิ่มเติม

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

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

 
GN⁺ 2024-04-05
ความเห็นจาก Hacker News

  • ผู้เขียนน่าจะทำได้ดีกว่านี้ถ้า บูต Mac จากอุปกรณ์เก็บข้อมูลภายนอก แล้วลบไฟล์ที่ไม่จำเป็นออกจากดิสก์ภายใน: Use an external storage device as a Mac startup disk
    สิ่งที่น่าแปลกคือบน Mac ที่ใช้ Apple Silicon ไม่ใช่ว่าทุกพอร์ตจะเท่าเทียมกันเมื่อบูตจากภายนอก
    เวลาติดตั้ง macOS ลงในอุปกรณ์เก็บข้อมูล Mac โน้ตบุ๊กต้องหลีกเลี่ยงพอร์ต USB-C ซ้ายสุดในบรรดาพอร์ตฝั่งซ้าย และ iMac/Mac mini/Mac Studio/Mac Pro ก็มีพอร์ต USB-C ที่ควรหลีกเลี่ยงแตกต่างกันไปตามรุ่น
    แต่พอติดตั้งเสร็จแล้วจะเสียบเข้าพอร์ตไหนก็ได้

    • ได้ลองทำแบบที่เสนอไว้ไปแล้ว ซึ่งแทบจะเหมือนกันทุกประการ
      ผู้เขียนบูตเข้า recoveryOS ซึ่งเป็นพาร์ทิชันแยกต่างหาก แล้วพยายามลบไฟล์จากพาร์ทิชันระบบหลัก แต่ rm ก็ล้มเหลวด้วยข้อผิดพลาด No space left on device แบบเดียวกัน
      เพราะแบบนั้น วิธีตัดไฟล์ให้สั้นลงด้วย echo -n >file อย่างที่คนอื่นพูดถึง อาจจะใช้ได้ผล
    • ถ้าตัวระบบไฟล์เองเข้าสู่ภาวะ deadlock การลบไฟล์ผ่านไดรเวอร์ของระบบไฟล์จะใช้ไม่ได้ ไม่ว่าจะบูตจากที่ไหนก็ตาม
    • ถ้าแม้แต่ recoveryOS หรือโหมด Mac Share Disk/Target Disk ก็ยังใช้ไม่ได้ ก็สงสัยว่าทำไมถึงคิดว่าวิธีนั้นจะใช้ได้
    • คอมเมนต์แบบนี้น่าจะเป็นอะไรที่น่ายินดีมากสำหรับใครสักคนที่มาเจอจากการค้นหาเพื่อแก้ปัญหา Mac เก่าในตอนนั้นอีก 8 ปีให้หลัง
    • สงสัยว่ามีใครรู้ไหมว่าทำไมเวลาสร้าง OS ที่บูตได้บน Mac โน้ตบุ๊กถึงห้ามใช้ พอร์ต USB-C แรก

  • ถ้าเดาจากความรู้เล็กน้อยเกี่ยวกับโครงสร้างดิสก์ HFS+ ก็น่าจะเป็นไปได้ว่า ไฟล์ journal ก็เต็มด้วย และการลบต้องเขียนลง journal รวมถึงบางครั้งอาจต้องขยายมันด้วย เลยกลายเป็นสภาพประหลาดที่แม้แต่การลบเองก็ต้องใช้พื้นที่เพิ่มชั่วคราว
    macOS ยังคงเขียนไฟล์ต่อไปจนเหลือพื้นที่ว่างในไดรฟ์เพียง 41KB
    ผมเคยเผลอเติม NTFS กับ FAT32 จนเหลือ 0 ไบต์ และตอนนั้นก็ยังลบอะไรบางอย่างได้
    ลองค้นในฟอรัมดูพบว่า Sonoma ทำขั้นตอนเมานต์ผ่านเครือข่ายแบบ SMB/Samba สำหรับการกู้คืนด้วย Time Machine พัง และดูเหมือนใน 14.4 ก็ยังไม่มีวิธีแก้อยู่ดี
    จากประสบการณ์ SMB ไม่น่าเชื่อถือและมีบั๊กเยอะเกินไปมาตั้งแต่ราว ๆ 10.12~10.13 แล้ว และตอนนี้ดูเหมือน Apple จะไม่ค่อยสนใจด้วยซ้ำว่ามันยังใช้งานได้หรือไม่
    ไม่อยากนึกเลยว่าคนที่ไม่มีประสบการณ์ใช้ Mac มาหลายสิบปีจะทำอย่างไรเมื่อเจอ ความล้มเหลวของระบบเป็นลูกโซ่ แบบนี้
    ผมเองก็ไม่ได้มีประสบการณ์กับ Mac มาหลายสิบปี แต่ถ้าเป็นสถานการณ์นี้คงลอง fsck ก่อนเป็นอย่างแรก เลยแปลกที่ไม่มีการพูดถึงตรงนี้
    ถ้าไม่สามารถคัดลอกข้อมูลในดิสก์ไปอีกลูกแล้วฟอร์แมตและคัดกลับได้ ผมคงไปเปิดเอกสาร APFS (https://developer.apple.com/support/downloads/Apple-File-System-Reference.pdf) แล้วหาดูว่าจะใช้ dd กับตัวแก้ไขเลขฐานสิบหกไปแก้ตรงไหนเพื่อทำให้มีพื้นที่ว่างขึ้นมาได้

    • นั่นใช้กับระบบไฟล์แบบ journaling แต่สำหรับ ระบบไฟล์ copy-on-write (CoW) การเปลี่ยนแปลงทั้งหมดจะเกิดขึ้นโดยสร้าง tree ของไฟล์ชุดใหม่ แล้วให้ root ชี้ไปยัง tree ใหม่นั้น
      จากนั้น garbage collection จะค้นหาไฟล์ที่ไม่ได้อยู่ใน tree ที่ใช้งานอยู่แล้ว และคืนพื้นที่เก็บข้อมูลกลับมา
      โดยทั่วไปจะรวมการเปลี่ยนแปลงเป็นชุดเพื่อลดปริมาณการแก้ไข tree ให้อยู่ในระดับที่จัดการได้ และด้วยการออกแบบนี้ snapshot ของระบบไฟล์ก็กลายเป็นอีกหนึ่ง reference ไปยัง tree ใด tree หนึ่ง
      กระบวนการนี้ต้องใช้พื้นที่ แต่ระบบไฟล์แบบ CoW มักจะกันพื้นที่ฉุกเฉินไว้สำหรับเหตุผลนี้อยู่แล้ว
    • Apple เลิกใช้ Samba ไปนานแล้วหลังจากที่ Samba เปลี่ยนไปใช้ GPLv3 และหันไปทำของตัวเองแทน: https://lists.samba.org/archive/samba-announce/2007/000122.html, https://www.engadget.com/2011-03-24-apple-to-drop-samba-networking-tools-from-lion.html
    • ตามสไตล์ Apple ประสิทธิภาพ SMB เมื่อหลายปีก่อนแย่มาก และช่วงหลังก็เพิ่งจะอยู่ในระดับพอรับได้เท่านั้น ยังช้ากว่า NFS บนฮาร์ดแวร์เดียวกัน หรือแม้แต่ Appleshare อย่างน่าขัน
      เมื่อหลายปีก่อนตอนต่อ Hackintosh เข้ากับ NAS ขนาดใหญ่ผ่าน 10GbE แล้ววัดด้วย BlackMagic Disk Speed Test ได้ว่า SMB บน Windows อยู่ที่ 900MB/s, SMB บน macOS อยู่ที่ 200MB/s, ส่วน NFS และ AFP บน macOS ได้ 1000MB/s ทั้งคู่
      ฟีเจอร์ macOS ที่เกี่ยวข้องกับงานระดับมืออาชีพนั้นน่าเสียดายที่อยู่ในระดับน่าขัน
      หลายคนบอกว่า AFP ตายแล้ว แต่บน Mac Pro ของผมมันยังทำงานได้ดีในฐานะไคลเอนต์ และประสิทธิภาพก็ดีกว่า SMB มากจนแทบจะตลก
    • ถ้าเจอกับตัวเองคงไม่ขำ แต่เรื่องแบบเดียวกันนี้เกิดขึ้นได้กับ BTRFS และ ZFS เช่นกัน
      ถ้าปล่อยให้เต็มจนสุดก็อาจมีปัญหาได้
      BTRFS พยายามสลับเป็นโหมดอ่านอย่างเดียวตอนที่ยังเหลือพื้นที่สำหรับ metadata อยู่ เพื่อให้เมานต์กลับใน safe mode แล้วลบอะไรบางอย่างออกได้ แต่ก็ไม่ใช่กลไกป้องกันที่สมบูรณ์แบบ
      เท่าที่ผมรู้ NTFS และ FAT32 ไม่ใช่ระบบไฟล์แบบ journaling
    • ตอนนี้นี่ดูเหมือนจะเป็น คำอธิบายทางเทคนิค ที่ใช้ได้จริงเพียงอันเดียว

  • ตอนทำงานที่แรกก็เคยเจอแบบนี้
    เผลอทำให้คลัสเตอร์เต็มไปด้วยไฟล์ขยะ แล้วผู้ดูแลระบบก็เริ่มส่งอีเมลมาเร่งให้รีบแก้ แต่ rm กลับใช้ไม่ได้
    ตอนนั้นได้เรียนรู้ว่าต่อให้ลบไม่ได้ การ truncate ไฟล์ มักจะยังทำได้อยู่ ดังนั้นเวลาที่ rm foo ไม่ได้ ก็มักใช้ cat /dev/null > foo แทนได้

    • ในเชลล์ :>filepath ก็มักใช้ได้
      แต่บางไฟล์ซิสเต็มอาจทำแบบนั้นไม่ได้เหมือนกัน
      ในกรณีนั้นก็ต้องหวังว่าไฟล์ซิสเต็มจะรองรับการขยายขนาด ลดขนาด หรือเพิ่มพื้นที่ชั่วคราวได้ หรือไม่ก็หวังว่าจะเพิ่ม/ถอดแบ็กกิงสตอเรจจากระบบชั้นล่างได้
      บางทีอาจต้องใช้คำสั่งแยกต่างหากเพื่อย้อนกลับไปเป็นโครงสร้างสำหรับอุปกรณ์บล็อกเดี่ยวแบบ btrfs
    • หลายปีก่อน เคยมีสถานการณ์ที่โครงสร้างพื้นฐานสำคัญซึ่งต้องเขียนลงไฟล์ซิสเต็มได้ตลอดเวลา อาจพังแบบกู้คืนไม่ได้จากภาวะชะงักงัน
      เลยทำให้โปรเซสแบ็กอัปส่งข้อมูลขยะไปที่ /dev/null โดยตรงเป็นระยะ ๆ และแฮ็กสกปรก ๆ นั้นก็น่าจะยังทำงานอยู่จนถึงทุกวันนี้
      /dev/null นี่เหมือนเวทมนตร์ ควรค่าแก่การลองอ่านดูสักครั้ง
    • จริง ๆ แค่ >file ก็พอแล้ว
    • แต่ก็มีกรณีแบบที่หลายคอมเมนต์ในนี้พูดถึง คือแม้แต่ truncate ก็ยังล้มเหลว
      ฟอร์แมตไฟล์ซิสเต็มในศตวรรษที่ 21 ซับซ้อนกว่า UFS มาก และฟีเจอร์อย่าง snapshot กับ journaling ก็สร้างวิธีใหม่ ๆ ที่ทำให้ไฟล์ซิสเต็มชะงักงันด้วยตัวเองได้
    • เคยตั้งระดับล็อกของ Samba สูงเกินไปเพราะดีบัก แล้วลืมปรับกลับ จนทำให้ไฟล์ล็อกมหึมาไปเติมเต็ม ZFS root SSD
      สุดท้ายต้องกู้ด้วย truncate
      ถึงจะรู้อยู่ว่า ZFS รับมือสถานการณ์แบบนี้ได้ดีกว่า แต่ความรู้สึก “อา... ฉิบหายแล้ว” ตอนรู้ว่าพังจริงก็ยังจุกเหมือนเดิม

  • เหมือน Time Machine จะแย่ลงเรื่อย ๆ
    ไม่เข้าใจว่าทำไมถึงไม่มีแรงจูงใจให้ทำให้มันเสถียรและใช้งานได้จริง
    เจอทั้ง sparse bundle เสียจนต้องเริ่มแบ็กอัปใหม่ หรือฟังก์ชันล้มเหลวซ้ำ ๆ จนตอนนี้รู้สึกว่าแทบไม่คุ้มจะตั้งค่า Time Machine แล้ว
    ต่างจากการแบ็กอัป iOS/iPadOS ที่ใช้งานได้ดีมาตลอดอย่างสิ้นเชิง

    • เพราะไม่ได้ขาย Time Capsule แล้ว
      Apple อยากให้คนไปแบ็กอัปทุกอย่างไว้บน iCloud เพื่อเพิ่มรายได้จากบริการ
    • ในมุมของคนที่ไม่ได้ใช้ Mac ถ้าเรื่องนี้เกิดกับเดสก์ท็อประบบปฏิบัติการที่มีมาสคอตเป็นเพนกวินหรือมีสำนักงานใหญ่ในวอชิงตัน มันคงถูกด่าว่าเป็น บั๊กระดับหายนะที่ไม่มีข้อแก้ตัว
    • นับครั้งไม่ถ้วนแล้วที่ Time Machine อยู่ ๆ ก็ตัดสินใจว่าไม่อยากทำงานต่อ แล้วต้องลบแบ็กอัปทิ้งแล้วเริ่มใหม่
    • การควบคุมคุณภาพของ macOS แย่ลงมาตั้งแต่ไล่ Scott Forstall ออก และจริง ๆ ต่อให้ตอนเขายังอยู่ก็ไม่ได้ยอดเยี่ยมอะไรนัก
    • ประสบการณ์ของฉันต่างออกไป
      ใช้ Time Machine บน Samba share กับ Mac หลายเครื่องมาหลายปีแล้ว และเห็นแต่การพัฒนาที่ดีขึ้น
      เมื่อก่อน sparse bundle ของ Time Machine เสียบ่อย จนต้องสร้างใหม่ หรือไม่ก็ restore ZFS snapshot เก่ามาแล้วทำต่อ
      ตอนนั้นน่าจะใช้ AFP ไม่ใช่ SMB
      ช่วงหลังมานี้ไม่เจอปัญหาแบบนั้นกับอุปกรณ์ไหนเลย และก็ได้เปิดแฟล็กบางตัวใน smb.conf ที่แนะนำสำหรับใช้กับแบ็กอัป Time Machine ไว้ด้วย

  • ในทางกลับกัน ZFS มี slop space ไว้เพื่อหลีกเลี่ยงกรณีที่พื้นที่หมดระหว่างงานใหญ่แล้วทำให้ไฟล์ซิสเต็มค้าง
    ค่าเริ่มต้นจะกันพื้นที่ไว้ 3.2% ของโวลุม สูงสุดไม่เกิน 128GB
    ดังนั้นถ้าปรับค่าจูนของเคอร์เนล Linux อย่าง spa_slop_shift เพื่อลด slop space ก็จะเอาพื้นที่โบนัสสำหรับให้การลบไฟล์ทำจนจบกลับคืนมาได้สูงสุด 128GB: https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Module%20Parameters.html#spa-slop-shift

    • ใช่
      ฟีเจอร์กันพื้นที่ดิสก์ไว้เป็นสัดส่วนแบบนี้เป็นความสามารถปกติของไฟล์ซิสเต็ม “จริงจัง” มาตั้งแต่หลายสิบปีก่อนจะมีทั้ง ZFS หรือ Linux เสียอีก
      คล้ายกับที่โปรแกรมเทอร์มินัลแบบแชร์แวร์บน MS-DOS ในยุค 1980 ส่วนใหญ่ดาวน์โหลดไฟล์ผ่านการเชื่อมต่อแบนด์วิดท์จำกัดได้ดีมาก แต่ MS Windows ปัจจุบันกลับทำงานเล็กน้อยแค่นั้นได้ห่วยมาก
    • ext4 ก็มีฟีเจอร์เดียวกัน แค่เรียกว่า reserved blocks
      ดูรายละเอียดได้ใน man tune2fs
      ไฟล์ซิสเต็มสมัยใหม่ส่วนใหญ่ หรือแม้แต่ที่ไม่ค่อยสมัยใหม่ ก็มีเหมือนกัน
      ถ้าจำไม่ผิด UFS ของ SunOS ในยุค 1980 ก็มีเช่นกัน: https://en.wikipedia.org/wiki/SunOS

  • คนจำนวนมากเข้าใจได้ยากว่าการลบอะไรสักอย่างอาจต้องใช้พื้นที่เพิ่มจริง ๆ ไม่ว่าจะชั่วคราวหรือถาวรก็ตาม
    คอมเมนต์อื่น ๆ อธิบายละเอียดแล้วว่าไฟล์ซิสเต็มสมัยใหม่อย่าง snapshot, journaling และอื่น ๆ ทำไมจึงต้องจัดสรรจากพื้นที่ว่างเพื่อทำการลบ
    ในอีกบริบทหนึ่ง ช่วง 10 ปีแรกของ Wikipedia ก็ต้องอธิบายอยู่บ่อย ๆ ว่าความพยายามลบหน้าเพื่อประหยัดพื้นที่เซิร์ฟเวอร์นั้นจริง ๆ แล้วกลับได้ผลตรงกันข้าม
    อย่างน้อยตั้งแต่ราวปี 2004 เป็นต้นมา การลบคือการเพิ่มเรคอร์ดเข้าไปในฐานข้อมูลภายใน
    ในฟอร์แมตอาร์ไคฟ์ ZOO ของ Rahul Dhesi การลบรายการเป็นแค่การตั้งแฟล็กในเฮดเดอร์เรคอร์ด และยังมีระบบเวอร์ชันไฟล์แบบ VMS ที่เมื่อเพิ่มเวอร์ชันใหม่ก็ไม่เขียนทับเวอร์ชันเก่า
    ในยุค MS/DR/PC-DOS และ FAT ถ้ามีการติดตั้งยูทิลิตีกู้ไฟล์ลบไว้ การลบไฟล์อาจต้องใช้พื้นที่เพิ่มเพื่อบันทึกรายการใหม่ในฐานข้อมูลที่เก็บข้อมูลสำหรับกู้คืน
    ยูทิลิตีบีบอัดดิสก์เก่าบางตัวถึงขั้นบีบอัดเมทาดาทาด้วย จึงเป็นไปได้ในกรณีหายากที่การเปลี่ยนแปลงเมทาดาทาจะทำให้อัตราการบีบอัดเปลี่ยน และทำให้ขนาดโวลุมที่มองเห็นจากภายนอกเพิ่มขึ้นจริง
    แนวคิดที่ว่า ลบแล้วจะได้พื้นที่คืน นั้นแพร่หลายมาก แต่ถ้าพูดกันให้เป๊ะ มันไม่ได้จริงเสมอไป

  • เคยเจอปัญหาเดียวกันนี้ในเดือนตุลาคม 2018 และทิ้งไว้ในคำถาม Stack Overflow ด้านล่าง
    โชคดีที่มี พาร์ทิชัน APFS เพิ่มเติมที่ลบได้ จึงพอเคลียร์พื้นที่ดิสก์ออกมาได้
    กว่าจะหาสาเหตุเจอก็ใช้เวลาพอสมควร และระหว่างนั้นก็ตื่นตระหนกอยู่ไม่น้อย
    https://apple.stackexchange.com/questions/338721/disk-full-terminal-in-recovery-mode-won-t-delete-files-boot-kernel-panics
    หลังเพิ่งอัปเดต macOS Mojave แล้วสร้าง .dmg ก็เผลอทำให้ดิสก์เต็มจนระบบค้าง
    พอรีบูตก็เกิด kernel panic จึงบูตเข้า recovery mode, mount ดิสก์ แล้วรัน rm /path/to/large/file ในเทอร์มินัล แต่กลับขึ้น No space left on device
    โดยเนื้อแท้แล้วมันคือปัญหาเดียวกับเธรด Unix จากปี 2008: https://www.unix.com/linux/69889-unable-remove-file-using-rm-disk-space-full.html
    แม้แต่ echo x > /path/to/large/file ก็ไม่ช่วย และต้องการคำแนะนำอื่นนอกจาก “ล้างไดรฟ์แล้วกู้คืนจากแบ็กอัป”

    • การสร้าง พาร์ทิชันเสริม ขนาดเล็กประมาณ 1GB ไว้อาจเป็นประกันที่ดี
      คล้ายกับที่ไฟล์ซิสเต็ม Unix สมัยก่อนจะกันพื้นที่ 5% ไว้สำหรับ root
    • ในโพสต์ StackExchange นั้นยังมีวิธีแก้ที่เป็นไปได้อื่น ๆ ถูกเพิ่มเข้ามาภายหลัง
      ถ้าลบ พาร์ทิชันหน่วยความจำเสมือน ก็อาจคืนพื้นที่มามากพอให้ลบไฟล์ได้ โดยมีเงื่อนไขว่าพาร์ทิชันนั้นต้องใหญ่พอ
    • แต่บน APFS มันไม่ได้ง่ายแบบนั้น
      เพราะคอนเทนเนอร์จะถูกจัดสรรจริงก็ต่อเมื่อมีการใช้งาน

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

    • เคยเห็น CockroachDB ทำแบบเดียวกันตอนเริ่มต้นโหนด: https://www.cockroachlabs.com/docs/v23.2/cluster-setup-troubleshooting#automatic-ballast-files
    • ข้อดีใหญ่ของไฟล์กันพื้นที่คือ เมื่อถึงเวลาจำเป็นก็สามารถคืนพื้นที่ก้อนนั้นเพื่อซื้อเวลาไว้จัดการ ทางออกระยะยาว
      เช่น ซื้อไดรฟ์ใหม่ที่ใหญ่กว่าเดิม 4 เท่า ซึ่งถูกกว่าต้นทุนเวลา 1 ชั่วโมงของพนักงานหรืออุปกรณ์เสียอีก

  • เคยเจอเรื่องคล้ายกันบน iPhone ด้วย
    ดิสก์เต็มมากจนถึงขั้นลบอะไรไปแล้วดูเหมือนไม่มีอะไรเกิดขึ้นจริง
    พอรีบูตก็ล็อกอินไม่ได้ แล้วพอรีบูตอีกทีก็เข้าสู่ boot loop
    พอรีบูตอีกครั้งก็ขึ้นมาในสภาพไม่สอดคล้องกัน คือยังมีไอคอนแอปอยู่บนหน้าจอหลัก แต่ตัวแอปจริงหายไป ไอคอนว่าง และเปิดใช้งานไม่ได้
    สุดท้ายก็กู้คืนจากแบ็กอัปเพราะกังวลเรื่องความสมบูรณ์ของข้อมูล
    ค่อนข้างมั่นใจว่านี่เป็นผลจากการที่ APFS ใช้ copy-on-write และรองรับ snapshot
    ถ้าการเปลี่ยนแปลงไม่ได้ถูกทำให้ถาวรทันที และไฟล์เวอร์ชันเก่ายังถูกเก็บไว้ใน snapshot ก็จะมีปัญหามากเมื่อแม้แต่ metadata ของ snapshot ยังไม่มีที่เหลือพอ
    ต่อให้ข้ามการสร้าง snapshot เมื่อพื้นที่ดิสก์ไม่พอ ก็ยังเหลือปัญหา metadata ของ CoW อยู่ดี

    • ฉันก็เจอเหมือนกันทุกอย่าง
      น่าทึ่งที่แม้ในปี 2024 จะมีฟีเจอร์จัดการโวลุม APFS อัจฉริยะมากมาย แต่แค่ทำให้พื้นที่ผู้ใช้เต็มก็ยังทำให้อุปกรณ์แบบ “ปิดผนึก” อย่าง iPhone เข้าสู่สภาพที่ต้อง กู้คืนผ่าน DFU ได้
      ตรงกันข้าม ตอนเผลอทำให้โน้ตบุ๊กทำงาน Windows 11 ที่ใช้โวลุมข้อมูล/บูตเดียวกันเต็ม ก็ยังบูตขึ้นมาและจัดการปัญหาได้อยู่

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

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