ทำไมระบบไฟล์จึงได้รับความสนใจ

 (madalitso.me)
36 คะแนน โดย GN⁺ 2026-03-09 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ในช่วงหลังนี้ ระบบนิเวศ AI เอเจนต์ หันกลับมาให้ความสนใจกับระบบไฟล์อีกครั้ง และมันกำลังก้าวขึ้นมาเป็น วิธีจัดการบริบทแบบต่อเนื่อง ที่แตกต่างจากฐานข้อมูล
  • context window ของ LLM ไม่ได้ใกล้เคียงกับความทรงจำถาวร แต่เหมือนกับ ไวท์บอร์ดที่ถูกลบอยู่ตลอดเวลา มากกว่า ขณะที่ระบบไฟล์คือวิธีจัดเก็บแบบถาวรที่เรียบง่ายที่สุดในการแก้ปัญหานี้
  • Claude Code, Cursor และเครื่องมืออื่น ๆ ใช้ การจัดเก็บบริบทบนไฟล์ เพื่อสร้างความทรงจำระยะยาว โดยไฟล์อย่าง CLAUDE.md และ aboutme.md ทำหน้าที่เก็บ ตัวตนของเอเจนต์และข้อมูลสภาพแวดล้อม
  • การจัดการบริบทบนระบบไฟล์ กำลังกลายเป็นประเด็นสำคัญ โดยบริษัทหลักอย่าง LlamaIndex, LangChain, Oracle และ Archil ต่างทยอยเผยแพร่บทความและผลิตภัณฑ์ที่เกี่ยวข้อง
  • ท่ามกลางการเพิ่มจำนวนของไฟล์บริบทสำหรับเอเจนต์อย่าง CLAUDE.md, AGENTS.md, .cursorrules รูปแบบ Agent Skills (SKILL.md) ของ Anthropic ถูกนำไปใช้โดย Microsoft, OpenAI, GitHub และ Cursor จนเกิดความสามารถในการทำงานร่วมกัน
  • ตามงานวิจัยของ ETH Zürich ไฟล์บริบทอาจกลับกลายเป็นว่า ลดอัตราความสำเร็จของงานและเพิ่มต้นทุนการอนุมานมากกว่า 20% ได้ ดังนั้นจึงควรระบุเฉพาะข้อกำหนดขั้นต่ำที่จำเป็น
  • ไฟล์ไม่ได้ผูกติดกับแอปใดแอปหนึ่ง และกำลังกลายเป็น อินเทอร์เฟซแบบเปิด ที่ทำให้การสลับเครื่องมือ การเชื่อมเวิร์กโฟลว์ และการรักษาความต่อเนื่องในยุค AI เอเจนต์เป็นไปได้

Everyone is talking about files : ทุกคนกำลังพูดถึงไฟล์

context window ไม่ใช่ความทรงจำ

  • ความทรงจำของมนุษย์มีทั้งการเก็บระยะยาว การเรียกคืนแบบเลือกสรร และความสามารถในการลืมข้อมูลที่ไม่จำเป็น แต่ context window ของ LLM ใกล้เคียงกับ ไวท์บอร์ดที่ถูกลบเรื่อย ๆ มากกว่า
  • เมื่อใช้ Claude Code หากการแจ้งเตือน "context left until auto-compact" เริ่มใกล้เข้ามา บริบทที่เอเจนต์สะสมไว้ เช่น โค้ดเบส ความชอบ หรือการตัดสินใจต่าง ๆ จะถูกบีบอัดหรือสูญหาย
  • ระบบไฟล์แก้ปัญหานี้ได้ด้วยวิธีที่ง่ายที่สุด: เขียนสิ่งที่ต้องจำลงไฟล์ แล้วอ่านกลับเมื่อจำเป็น
    • CLAUDE.md มอบ บริบทถาวร เกี่ยวกับโปรเจกต์
    • Cursor เก็บประวัติแชตเก่าไว้เป็นไฟล์ที่ค้นหาได้
    • ไฟล์ aboutme.md ทำหน้าที่เป็น ตัวบรรยายตัวตนแบบพกพา ที่เก็บความชอบ ทักษะ และสไตล์การทำงาน และสามารถย้ายข้ามแอปได้โดยไม่ต้องมีการประสานผ่าน API

งานวิจัย ETH Zürich: ความย้อนแย้งของไฟล์บริบท

  • งานวิจัยล่าสุดของ ETH Zürich ประเมินว่าไฟล์บริบทระดับรีโพซิทอรีช่วยให้ coding agent ทำงานสำเร็จได้จริงหรือไม่
  • ผลลัพธ์ออกมาตรงข้ามกับสัญชาตญาณ: ในหลายเอเจนต์และหลายโมเดล ไฟล์บริบทกลับ ลดอัตราความสำเร็จของงาน และเพิ่มต้นทุนการอนุมาน มากกว่า 20%
    • เอเจนต์ที่ได้รับไฟล์บริบทจะสำรวจวงกว้างขึ้น รันเทสต์มากขึ้น และวนดูไฟล์มากขึ้น แต่กลับไปถึงโค้ดที่ต้องแก้จริงช้าลง
    • ไฟล์ทำงานเหมือน เช็กลิสต์ ที่เอเจนต์ทำตามอย่างเคร่งครัดเกินไป
  • บทสรุปของงานวิจัยไม่ใช่ "อย่าใช้ไฟล์บริบท" แต่คือ ข้อกำหนดที่ไม่จำเป็นทำให้งานยากขึ้น และไฟล์บริบทควรเขียนเฉพาะข้อกำหนดขั้นต่ำเท่านั้น
  • ปัญหาไม่ได้อยู่ที่ชั้น persistence ของระบบไฟล์เอง แต่อยู่ที่แนวปฏิบัติในการเขียน CLAUDE.md ให้ยาวราว 2,000 คำเหมือนเอกสาร onboarding

รูปแบบไฟล์ก็คือ API — แต่เป็นไฟล์แบบไหน?

  • ตอนนี้มีทั้ง CLAUDE.md, AGENTS.md, copilot-instructions.md, .cursorrules อยู่ร่วมกัน แม้จะเห็นพ้องกันแล้วว่าเอเจนต์ต้องการบริบทถาวรบนระบบไฟล์ แต่ก็ยัง ไม่มีข้อสรุปเรื่องชื่อไฟล์และรูปแบบเนื้อหา
  • ในบทความ social filesystem ของ Dan Abramov มีแนวคิดการออกแบบสำคัญว่า AT Protocol ปฏิบัติต่อข้อมูลผู้ใช้เป็น ไฟล์ในรีโพซิทอรีส่วนตัว และให้แอปหลีกเลี่ยงการชนกันด้วย namespace ที่อิงชื่อโดเมน โดยไม่จำเป็นต้องตกลงร่วมกันก่อนว่า "โพสต์" คืออะไร
    • ฐานข้อมูลของทุกแอปจึงกลายเป็นข้อมูลอนุพันธ์ หรือก็คือ มุมมองแบบ materialized ที่แคชไว้ ของโฟลเดอร์ผู้ใช้ทั้งหมด
  • Anthropic เปิดตัว Agent Skills เป็นมาตรฐานเปิด โดยรูปแบบ SKILL.md ถูกนำไปใช้โดย Microsoft, OpenAI, Atlassian, GitHub และ Cursor
    • สกิลที่เขียนสำหรับ Claude Code สามารถทำงานได้ใน Codex และ Copilot ด้วย — รูปแบบไฟล์ก็คือ API
  • NanoClaw เป็นเฟรมเวิร์ก AI assistant ส่วนบุคคลแบบน้ำหนักเบา ที่ใช้โมเดลแบบ "สกิลแทนฟีเจอร์"
    • หากต้องการรองรับ Telegram ก็ไม่ต้องมี Telegram module แต่ใช้สกิล /add-telegram (ไฟล์มาร์กดาวน์) เพื่อสอน Claude Code ถึงวิธีรวมเข้าด้วยกัน
    • เพราะสกิลเป็นไฟล์ จึงเคลื่อนย้ายได้ ตรวจสอบได้ และประกอบรวมกันได้ — ไม่ต้องมี MCP server หรือปลั๊กอินมาร์เก็ตเพลส
  • นี่คือ การทำงานร่วมกันได้โดยไม่ต้องประสานกันล่วงหน้า: ถ้าแอปสองตัวอ่านมาร์กดาวน์ได้ ก็แชร์บริบทกันได้ และถ้าเข้าใจรูปแบบ SKILL.md ก็แชร์ความสามารถกันได้ โดยไม่ต้องมีสัญญาพาร์ตเนอร์หรือการประชุมขององค์กรกำหนดมาตรฐาน เพราะตัวรูปแบบไฟล์เองทำหน้าที่เป็นกลไกประสานงาน

คอขวดได้ย้ายตำแหน่งแล้ว

  • สถาปัตยกรรมข้อมูลแบบดั้งเดิมถูกออกแบบบนสมมติฐานว่า storage คือคอขวด แต่เมื่อความสามารถในการประมวลผลแซง storage I/O กระบวนทัศน์ก็เปลี่ยนไปสู่ การแยก storage ออกจาก compute (S3 + คลัสเตอร์คอมพิวต์ชั่วคราว)
  • ใน AI agent ก็เกิดปรากฏการณ์คล้ายกัน: คอขวดไม่ใช่ประสิทธิภาพของโมเดลหรือ compute แต่เป็น บริบท
    • โมเดลฉลาดพอแล้ว แต่ขี้ลืม
    • ระบบไฟล์คือ วิธีที่มีประสิทธิภาพที่สุดในการจัดการบริบทถาวร ณ จุดที่เอเจนต์ทำงานอยู่จริงพอดี (เครื่องของนักพัฒนา สภาพแวดล้อม และข้อมูลที่มีอยู่แล้ว)

ระบบไฟล์เป็นกราฟอยู่แล้ว

  • มีคนชี้บน Twitter ว่า "คนที่ใช้ระบบไฟล์แต่บอกว่าเอเจนต์ไม่ต้องการกราฟ กำลัง ปฏิเสธว่าตัวเองใช้กราฟอยู่"
    • ระบบไฟล์ประกอบด้วยไดเรกทอรี ไดเรกทอรีย่อย และไฟล์ ซึ่งเป็น โครงสร้างแบบต้นไม้ หรือก็คือ directed acyclic graph (DAG)
    • เมื่อเอเจนต์ใช้ ls, grep, อ่านไฟล์ หรือไล่ตามการอ้างอิง มันก็กำลังเดินกราฟอยู่แล้ว
  • Richmond ในบทความของ Oracle ให้ภาพแยกที่เฉียบคมที่สุด: ระบบไฟล์ชนะในฐานะอินเทอร์เฟซ ส่วนฐานข้อมูลชนะในฐานะชั้นโครงสร้างพื้นฐาน
    • เมื่อคุณต้องการการเข้าถึงพร้อมกัน การค้นหาเชิงความหมายขนาดใหญ่ การลบข้อมูลซ้ำ หรือการถ่วงน้ำหนักตามความใหม่ คุณก็จะลงเอยด้วยการสร้างดัชนีของตัวเอง ซึ่งก็คือฐานข้อมูลนั่นเอง
  • อินเทอร์เฟซแบบไฟล์ทรงพลังเพราะเป็นสากลและ LLM เข้าใจอยู่แล้ว ขณะที่ชั้นฐานข้อมูลก็ทรงพลังเพราะให้การรับประกันที่จำเป็นต่อการใช้งานจริง
  • อนาคตจึงไม่ใช่ไฟล์ปะทะฐานข้อมูล แต่คือโครงสร้างที่ ไฟล์เป็นอินเทอร์เฟซที่มนุษย์และเอเจนต์ใช้โต้ตอบ และด้านล่างมีชั้นโครงสร้างพื้นฐานที่เหมาะกับแต่ละ use case

นี่คือการนิยาม personal computing ใหม่

  • ระบบไฟล์อาจ นิยามความหมายของ personal computing ใหม่ ในยุค AI
    • ข้อมูล บริบท ความชอบ สกิล และความทรงจำ อยู่ในรูปแบบที่ผู้ใช้เป็นเจ้าของ เอเจนต์ใดก็อ่านได้ และไม่ถูกล็อกไว้กับแอปใดแอปหนึ่ง
    • aboutme.md ใช้งานได้ทั้งใน OpenClaw/NanoClaw วันนี้ และในเครื่องมือใหม่วันหน้า
    • ไฟล์สกิลย้ายข้ามที่ได้ และบริบทของโปรเจกต์ก็ยังคงอยู่ข้ามเครื่องมือ
  • นี่คือภาพที่ personal computing เคยตั้งใจจะเป็น ก่อนที่ทุกอย่างจะย้ายไปอยู่ใน แอป SaaS แบบปิดและฐานข้อมูลแบบปิดกรรมสิทธิ์
    • ไฟล์คือ โปรโตคอลแบบเปิดดั้งเดิม และเมื่อ AI agent กลายเป็นอินเทอร์เฟซหลักของการประมวลผล มันก็กลายเป็นชั้นการทำงานร่วมกันที่ทำให้การสลับเครื่องมือ การเชื่อมเวิร์กโฟลว์ และการรักษาความต่อเนื่องระหว่างแอปเกิดขึ้นได้ โดยไม่ต้องขออนุญาตใคร
  • อย่างไรก็ตาม ยังมีด้านที่เป็นอุดมคติอยู่: ในประวัติศาสตร์ของฟอร์แมตแบบเปิด มีมาตรฐานจำนวนมากที่ชนะบนเอกสารแต่แพ้ในการใช้งานจริง
    • บริษัทต่าง ๆ มีแรงจูงใจที่จะทำไฟล์บริบทของตัวเองให้ต่างกันเล็กน้อย เพื่อ รักษาต้นทุนการย้ายออก
    • การที่ CLAUDE.md, AGENTS.md และ .cursorrules ยังอยู่ร่วมกันแทนที่จะรวมเป็นรูปแบบสากลเดียว ก็แสดงให้เห็นว่า การแตกเป็นเสี่ยง ๆ คือค่าตั้งต้น
    • งานวิจัยของ ETH Zürich เตือนด้วยว่า ถึงจะมีรูปแบบอยู่แล้ว การเขียนไฟล์บริบทที่ดีก็ยังยาก และไฟล์บริบทที่แย่อาจแย่กว่าไม่มีเลย
  • ข้อความสำคัญของ Dan Abramov คือ

    ความทรงจำ ความคิด และงานออกแบบของเรา ควรอยู่รอดได้นานกว่าซอฟต์แวร์ที่สร้างมันขึ้นมา

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

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

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

 
GN⁺ 2026-03-09
ความเห็นจาก Hacker News

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

    • ด้วย ความสามารถในการให้เหตุผล ของ LLM ตอนนี้เราไม่จำเป็นต้องกังวลกับโครงสร้างไฟล์อีกต่อไป
      ภาษาธรรมชาติสามารถอยู่ภายในไฟล์ได้เลย และความอ่านง่ายก็คือสเปกในตัว
      ใครก็ตามที่เขียนให้อ่านง่ายได้ก็สามารถเขียนลงไฟล์ได้ และรันได้ทันทีเหมือน REPL
    • เพราะแบบนี้ ความพยายามของบริษัทยักษ์ใหญ่อย่าง Apple ที่จะลบแนวคิดเรื่องไฟล์ออกไปจึงน่ากังวล
      มันทำให้ข้อมูลถูกผูกติดกับแอปและไม่สามารถมีอยู่ได้อย่างอิสระ และยังทำให้การนำเข้า/ส่งออกทำได้ยาก
      ผมกำลังสร้างเครื่องมือเพื่อแก้ปัญหานี้ โดยดึงข้อมูลจากแบ็กอัปออกมาเป็น หน่วยไฟล์แบบละเอียด แล้วนำไปเก็บไว้ในห้องสมุดดิจิทัลส่วนตัว
      สำหรับข้อมูลที่ไม่เปลี่ยนแปลง การเก็บถาวรก็เพียงพอ แต่สำหรับข้อมูลที่แก้ไขได้ ความท้าทายใหญ่ที่สุดคือทำให้มันกลับมาอยู่ในรูปแบบที่ “มีชีวิต” และแก้ไขในแอปได้อีกครั้ง
    • ผมคิดว่าไฟล์คอนฟิกดีกว่าที่เก็บข้อมูลส่วนกลางอย่าง Windows Registry มาก
      ง่ายต่อการเปลี่ยนชั่วคราวและการแชร์ และความหมายของการตั้งค่าก็ถูกกำหนดไว้อย่างชัดเจน
      ผมไม่ชอบที่ Windows ปฏิบัติต่อไฟล์เหมือนเป็น พลเมืองชั้นสาม

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

    • ระบบจัดการรูปภาพของผมที่ใช้งานมานานกว่า 10 ปี ใช้ไฟล์ซิสเต็มและ EXIF เป็น แหล่งความจริง
      นี่เป็นแนวทางที่ถูกต้องและผ่านการพิสูจน์มาหลายครั้งแล้ว
      ชั้น abstraction อย่าง Google Photos หรือ Immich มีไว้เพื่อความสะดวกเท่านั้น แก่นสำคัญยังคงเป็นไฟล์
      ในงาน ผมก็จัดการงานวิจัยและเอกสารด้วยไฟล์ markdown และ csv
      ลิงก์โปรเจ็กต์ elodie
    • ปัญหาของการจัดการรูปภาพทุกวันนี้คือข้อมูลการแก้ไข แท็ก และอัลบั้มทั้งหมดถูกเก็บเป็น metadata ภายนอก
      ถ้าย้ายแพลตฟอร์ม ประวัติการแก้ไขทั้งหมดก็หายไป
      ฟังก์ชันย้อนกลับนั้นสะดวกก็จริง แต่ผมหวังว่าการเปลี่ยนแปลงแบบนี้จะถูกทำให้เป็นมาตรฐานเพื่อให้ ย้ายข้ามระบบได้

  • อยากพูดถึง Plan 9 ของ Bell Labs
    Plan 9 from Bell Labs

    • ผมกำลังสร้างตัว orchestration สำหรับเอเจนต์ชื่อ agenc
      ตอนถาม Claude เรื่องงานที่เกี่ยวข้องก่อนหน้า มันเสนอ Plan 9 ขึ้นมา ซึ่งนั่นแหละคือแนวคิดที่เราต้องการในตอนนี้
      ปรัชญาเรื่องการลดสิทธิ์ของเอเจนต์ให้เหลือน้อยที่สุดก็เหมือนกับโมเดลความปลอดภัยขององค์กร
      แค่ Plan 9 เกิดเร็วเกินไปเท่านั้นเอง
    • ถ้าจะดูไฟล์ซิสเต็มใหม่ ๆ GeFS ก็น่าลองศึกษา

  • ยิ่งทำให้ตระหนักว่า Plan 9 กับ UNIX มาถูกทางแล้ว
    อินเทอร์เฟซที่ทรงพลังที่สุดคือ ไฟล์ข้อความ บนไฟล์ซิสเต็ม
    ถึงเวลาที่ต้องสร้าง 9p2026 ขึ้นมาอีกครั้งแล้ว
    แต่แนวคิดพื้นฐานบางส่วนในบทความนี้ผิด — ไฟล์ซิสเต็มไม่ใช่ต้นไม้ แต่เป็น กราฟที่วนกลับได้

    • ผมสงสัยว่าคุณสมบัติแกนหลักของ Plan 9 คืออะไร ต่อผ่าน FUSE ได้หรือไม่ หรือจำเป็นต้องมีเวทมนตร์ที่ลึกกว่านั้น

  • นี่เป็นเรื่องที่ผมอินมากเหมือนกัน
    ตลอดปีที่ผ่านมา ผมย้ายข้อมูลส่วนตัวจาก SaaS กว่าสิบตัวมาไว้ในโครงสร้างไดเรกทอรีเดียว
    ไฟล์ซิสเต็มที่จัดระเบียบดี ก็เพียงพอสำหรับผู้ใช้คนเดียว และช่วยลบการแตกกระจายของข้อมูลได้
    ต่อไปผมคิดว่าเราจะได้เห็นฐานข้อมูลแบบใหม่ที่รองรับการเขียนพร้อมกันหลายผู้ใช้ได้อย่างปลอดภัย โดยไม่ทำให้ไฟล์ซิสเต็มกลายเป็นกล่องดำ
    ให้ความรู้สึกคล้ายกับบทบาทที่ QMD ทำเพื่อการค้นหา

  • ตอนนี้การใช้ AI ยังอยู่ในช่วงที่ ยังไม่สุกงอม
    ระบบ production จะทำงานบนโครงสร้างข้อมูลที่สม่ำเสมอและขยายได้ แต่เอเจนต์ที่สร้างมันขึ้นมาจะใช้เทคโนโลยีที่อิงไฟล์ซิสเต็ม
    UI น่าจะพัฒนาออกจากเดสก์ท็อปไปสู่ อินเทอร์เฟซเสียงและภาพ
    เช่น ในวิดีโอคอล มันอาจอ่านสีหน้าและน้ำเสียงเพื่อรับบริบทได้มากขึ้น

    • ใน วิดีโอเดโม AI ที่ผมเพิ่งดู มันดึงบริบทจากเสียงและท่าทาง แล้วแปลงเป็นข้อความก่อนส่งเข้า LLM
      ยังไม่ใช่มัลติโหมดเต็มรูปแบบ แต่ก็น่าสนใจมาก
    • ถึงอย่างนั้น การป้อนข้อความ ก็คงไม่หายไป
      การเขียนช่วยจัดระเบียบความคิด และไม่ได้ฉับพลันเหมือนการพูด
      ต่อให้การรู้จำเสียงพูด (STT) จะดีแค่ไหน สติปัญญาของมนุษย์ก็ยังทำงานโดยมีการเขียนเป็นศูนย์กลาง

  • ไฟล์จะมีประโยชน์ก็ต่อเมื่อหาเจอ
    นั่นคือการค้นหาและดัชนีเป็นสิ่งจำเป็น แต่พอขนาดใหญ่ขึ้น มันก็เริ่มพัง
    เพราะงั้นคำถามสำคัญคือ ‘ฐานความรู้ที่เอเจนต์จัดการได้มีขนาดเท่าไร’
    ผมวิเคราะห์ประเด็นนี้จากหลักการพื้นฐานไว้ใน บทความ “a good agentic KB”

  • ในหลายไฟล์ที่จัดระเบียบดีอย่างโค้ดเบส coding agent จะค้นหาข้อมูลได้ดี
    แต่ข้อมูลที่ยุ่งเหยิงนั้นจัดโครงสร้างแบบไฟล์ซิสเต็มได้ยากกว่ามาก
    มันซับซ้อนกว่าการค้นหาเชิงความหมายใน vector DB
    โค้ดเบสรักษาโครงสร้างแบบกราฟไว้ได้โดยธรรมชาติจากหลัก DRY แต่ข้อมูลที่ไม่ใช่โค้ดไม่เป็นแบบนั้น
    เพราะงั้นผมเห็นด้วยว่าไฟล์ซิสเต็มเป็นโครงสร้างบริบทที่ดีในระยะยาว แต่ตอนนี้มันยังแทนที่การค้นหาได้ไม่หมด

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

    • ข้อดีของไฟล์ซิสเต็มคือ การคงไว้ซึ่งความเป็นท้องถิ่นของการเปลี่ยนแปลง
      การเปลี่ยนแปลงในกิ่งหนึ่งจะไม่กระทบอีกกิ่งหนึ่ง
      ในทางกลับกัน ฐานข้อมูลอาจมี UPDATE หรือ DELETE ที่กระทบทั้งระบบได้ซึ่งอันตราย
      ดังนั้นแนวทางประนีประนอมแบบเอาดัชนี DB มาวางบนโครงสร้างต้นไม้แบบ OS สมัยใหม่จึงน่าจะเหมาะที่สุด
    • NTFS ใช้ ฐานข้อมูล MFT ภายใน
      มันทำดัชนีชื่อไฟล์ด้วย b+tree และเก็บข้อมูลไฟล์ไว้ใน MFT ด้วย
      ไดเรกทอรีเป็นเพียงแถวที่มีแอตทริบิวต์ ‘directory=true’ เท่านั้น
      แนวทางเชิงสัมพันธ์แบบเต็มตัวอย่าง WinFS ล้มเหลวเพราะปัญหาด้านประสิทธิภาพ และ Skydrive ก็เข้ามาแทนที่ตำแหน่งนั้น
    • ในไฟล์ซิสเต็มส่วนใหญ่ ไฟล์จะถูก ระบุเอกลักษณ์ ด้วย inode และสามารถถูกอ้างอิงได้จากหลายลิงก์
      ดูเหมือนคนจะลืมจุดนี้กันบ่อย
    • UUID อาจไม่โปร่งใสสำหรับมนุษย์ แต่สำหรับเอเจนต์มันคือตัวระบุที่แยกแยะได้อย่างสมบูรณ์
      สุดท้ายแล้วเราอาจมุ่งไปสู่แนวทางแบบเอาอินเด็กซ์ที่ดีไปวางบน blob storage สไตล์ S3 และให้ไดเรกทอรีถูก สร้างตามต้องการ เหมือนแท็ก
      เหลือไว้แค่ความสามารถในการจัดกลุ่มอย่างเช่น “ไฟล์ที่เกี่ยวกับ Q3 อยู่ในไดเรกทอรีนี้”