- SourceFS คือระบบไฟล์เสมือนประสิทธิภาพสูงที่ออกแบบมาเพื่อแก้ปัญหา ความเร็วและประสิทธิภาพของการ build ในโค้ดเบสอุปกรณ์ขนาดใหญ่
- ช่วย เพิ่มความเร็วการ build ของ Android ได้สูงสุด 9 เท่า และเพิ่มความเร็วการ checkout โค้ดมากกว่า 10 เท่า พร้อมลดการใช้ดิสก์ลง 83% และลดต้นทุนคอมพิวต์ได้ 14 เท่า
- หลักการสำคัญคือ การทำไฟล์ให้เป็นเสมือนและการ materialization แบบ on-demand โดยไฟล์จะดูเหมือนมีอยู่จริง แต่จะโหลดเนื้อหาเมื่อจำเป็นเท่านั้น
- ในกระบวนการ build ใช้ แคชชิงแบบ sandbox ที่บันทึกและนำอินพุต/เอาต์พุตกับสภาพแวดล้อมกลับมาใช้ซ้ำ ทำให้สามารถ replay ขั้นตอนการ build ส่วนใหญ่ได้ทันที
ปัญหาของการ build และการ checkout โค้ดที่ช้า
- อุปกรณ์เชื่อมต่อสมัยใหม่ขับเคลื่อนด้วย โค้ดเบสระดับหลายร้อยล้านบรรทัด
- Linux kernel มีประมาณ 40 ล้านบรรทัด, Android AOSP มากกว่า 140 ล้านบรรทัด และอุปกรณ์จริงยังมีโค้ดรองรับฮาร์ดแวร์ ฟีเจอร์ปรับแต่ง และบริการต่าง ๆ เพิ่มเข้ามาจนเกิน 200 ล้านบรรทัด
- รถยนต์ไฟฟ้า (EV) มีมากกว่า 500 ล้านบรรทัด และยังเพิ่มขึ้นต่อเนื่องจากการอัปเดตซอฟต์แวร์
- การ checkout โค้ดต้องดาวน์โหลดข้อมูลหลายร้อย GB และการ build ต้องผ่านขั้นตอนหลายแสนขั้น
- เนื่องจากกราฟ dependency ไม่สมบูรณ์ แม้การเปลี่ยนแปลงเล็กน้อยก็อาจทำให้เกิด การ rebuild ขนาดใหญ่ หรือให้ผลลัพธ์ที่ผิดพลาด
- ผลลัพธ์คือเกิด การสูญเสียเวลาของนักพัฒนาวันละหลายชั่วโมง และ ต้นทุนคอมพิวต์ของ CI ที่พุ่งสูงขึ้น
Source File System (SourceFS)
- SourceFS ไม่ใช่ระบบ build แบบใหม่ แต่เป็น ระบบไฟล์เสมือนประสิทธิภาพสูง ที่ผสานเข้ากับ workflow เดิมได้
- ช่วยเร่งทั้งการ checkout และการ build ของโค้ดเบส Android อย่างมาก พร้อม แทบไม่มีภาระในการย้ายระบบ
- แกนหลักคือทำให้ทุกไฟล์เป็นเสมือน materialize เฉพาะตอนที่ต้องใช้ และจัดการทั้งหมดนี้แบบ โปร่งใสต่อผู้ใช้
- เร่งความเร็วการ checkout: สร้างตัวแทนไฟล์เสมือนของทั้งโค้ดเบส แล้วค่อยโหลดเนื้อหาเมื่อมีการเข้าถึง
- ไฟล์มองเห็นได้เหมือนไฟล์จริง แต่ไฟล์ส่วนใหญ่จะยังคงอยู่ในสถานะเสมือน จึงช่วยประหยัดพื้นที่ดิสก์
- รองรับ Git และ Repo อย่างสมบูรณ์
- เร่งความเร็วการ build: แต่ละขั้นตอนของการ build จะรันอยู่ใน sandbox น้ำหนักเบาที่บันทึกอินพุต/เอาต์พุตและสภาพแวดล้อม
- ขั้นตอนที่เหมือนเดิมสามารถนำผลลัพธ์กลับมาใช้ซ้ำได้โดยไม่ต้องรันใหม่ และรันใหม่เฉพาะส่วนที่เปลี่ยน
- ใช้ได้กับทั้งการคอมไพล์ การลิงก์ การแพ็กเกจ และการสร้างเอกสาร ครอบคลุมทั้งกระบวนการ build
- ภายในใช้ อัลกอริทึมแคชและ replay ประสิทธิภาพสูง, sandboxing ที่มีประสิทธิภาพ, และ แบ็กเอนด์ที่พัฒนาด้วย Rust
- สามารถขยายใช้งานได้ทั้งองค์กรโดยมีโอเวอร์เฮดแทบเป็นศูนย์
build เร็วขึ้น ใช้สตอเรจน้อยลง ลดต้นทุน
- การ checkout โค้ดในสภาพแวดล้อม SourceFS เร็วกว่าเดิมมากกว่า 20 เท่า
- นักพัฒนายังทำงานใน workflow เดิมแบบ Git tree ได้เหมือนเดิม เพียงแต่ทำงานในโฟลเดอร์ของ SourceFS
- การลดการใช้ดิสก์ เป็นข้อดีอย่างมากสำหรับนักพัฒนาอุปกรณ์ที่ต้องสลับไปมาระหว่างหลายโค้ดเบส
- แม้ต้องสลับระหว่างเวอร์ชันอุปกรณ์หลายรุ่นหรือแก้บั๊กขนาดใหญ่ ก็ยัง ทำงานได้เบาเหมือนรีโพซิทอรี GitHub ขนาดเล็ก
- ความเร็วการ build เพิ่มขึ้นได้สูงสุด 9 เท่า ทำให้เครื่องของนักพัฒนาทั่วไปก็สามารถจบการ build ขนาดใหญ่ได้อย่างรวดเร็ว
- วงจร feedback ของ CI pipeline สั้นลง ช่วย เพิ่มผลิตภาพการพัฒนาได้สูงสุด
- ผลด้านการลดต้นทุนสูงสุดถึง 14 เท่า
- ใช้ SourceFS บนเครื่องทั่วไปยังทั้งเร็วกว่าและถูกกว่าการใช้เครื่องประสิทธิภาพสูง
- ทำงานได้มากขึ้นภายใต้งบประมาณคอมพิวต์เท่าเดิม
เปรียบเทียบกับทางเลือกเดิม
- SourceFS ก้าวข้ามข้อจำกัดของแนวทางเดิม
- การย้ายไปใช้ระบบ build ใหม่อย่าง Bazel หรือ Buck2 ทำได้ยากในโปรเจกต์ขนาดใหญ่ และยิ่งซับซ้อนขึ้นอีกในโค้ดเบสอุปกรณ์ที่มีหลาย OS (เช่น Yocto, Android, QNX)
- SourceFS ให้การเพิ่มประสิทธิภาพในระดับเดียวกันได้โดยไม่ต้องย้ายระบบ
- compiler wrapper (เช่น REClient, Goma) ช่วยเร่งได้เพียงบางขั้นตอนของการ build และไม่ช่วยเรื่องการ checkout
- อีกทั้งยังพึ่งพาการ parse command-line flags จึงมี ความเสี่ยงที่จะเกิดข้อผิดพลาดที่คาดไม่ถึง
แผนในอนาคต
2 ความคิดเห็น
ดูเหมือนว่าจะมีการใช้งานอะไรที่คล้ายกันนี้บน Android อยู่แล้วนะครับ
ความเห็นจาก Hacker News
ดูเหมือนว่าสมาชิกบางส่วนของทีมจะเป็น อดีตพนักงาน Google แต่สิ่งนี้ต่างจาก srcfs ที่อิงกับ Piper ที่เรารู้จัก
มีจุดคล้ายกันอยู่บ้าง แต่แทบไม่มีรายละเอียดเชิงลึก และแม้แต่ เวอร์ชัน self-hosting ก็ใช้โมเดลราคาแบบ “Talk to us” เลยค่อนข้างน่าเสียดาย
แล้วเรื่องราคานี่ ถ้าเป็นทีมที่ดูแลโค้ดเบสระดับหลายหมื่นล้านบรรทัด ก็น่าจะพอจ่ายราคาแบบ “TalkToUs” ได้ไม่ใช่หรือ?
แม้แต่โอเพนซอร์สอย่าง Linux ก็ยังรันได้ดีบนแล็ปท็อปของผม
เห็นแล้วนึกถึง MVFS ของ ClearCase สมัยก่อน
ตอน build มันจะดักจับการเรียกอย่าง open(2), getenv(3) เพื่อบันทึกทั้งหมดว่าเครื่องมือไหนใช้ไฟล์เวอร์ชันอะไร ภายใต้ environment แบบไหน
ถ้าเงื่อนไขเหมือนเดิมก็จะ “winked-in” ผลลัพธ์เก่ากลับมาใช้ซ้ำได้ และยังทำ version control ในระดับ filesystem ได้ด้วย
ตัวอย่างเช่น เข้าถึงได้ในรูปแบบ file.c@@/trunk/branch/subbranch/3
ตัวเลขเวลาในหัวข้อดูรู้สึกว่าโอ้อวดไปหน่อย
เลยอดสงสัยไม่ได้ว่าพวกเขากำลังพยายามทำ EdenFS หรือพวก git fuse ให้เป็นสินค้าอยู่หรือเปล่า
ประมาณว่า “ขั้นตอน build ที่เหมือนเดิมจากครั้งก่อนจะถูกข้ามอัตโนมัติและนำผลลัพธ์กลับมาใช้” ฟังดูดีเกินไปจนกลับไม่น่าเชื่อ
ให้ความรู้สึกเหมือน คอนเทนต์มาร์เก็ตติ้งเชิงพาณิชย์ มากกว่า รายละเอียดทางเทคนิคแทบไม่มีเลย
ถ้าจะแชร์เคล็ดลับที่เคยได้ผลตอนทำงานเป็น build engineer ในอดีต ก็มีเช่น
build บน tmpfs, ใช้ symlink/hardlink กับไฟล์ใหญ่แทนการคัดลอก, ลด I/O ที่ไม่จำเป็นด้วย libeatmydata,
และเลือก cross-compiler ให้เหมาะสม
สิ่งที่สำคัญจริง ๆ คือการปรับจูน build system และทำ cache intermediate artifact ที่ไม่เปลี่ยนแปลง ให้ดี
สวัสดีครับ ผมคือ Serban ผู้ร่วมก่อตั้ง Source.dev
ขอบคุณสำหรับ upvote และการพูดคุยกัน ฟีดแบ็กแบบนี้มีความหมายมากสำหรับสตาร์ทอัประยะเริ่มต้น
ดีใจที่รู้สึกว่าสิ่งที่เรากำลังสร้างมีคุณค่าจริง ๆ
เห็นประโยค “SourceFS ทำให้ build เร็วขึ้น 9 เท่า” แล้วหลุดขำเลย
ยิ่ง build ช้า ก็ยิ่งมีเวลา ฝึกวิชาดาบ มากขึ้น ดังนั้น build ช้าก็มีข้อดีในแบบของมัน
คำกล่าวอ้างด้านประสิทธิภาพ ของพวกเขาดูล้ำกว่าระบบ distributed Android build ที่ผมเคยใช้มามาก
เลยสงสัยว่ามีซอสลับอะไรอยู่เบื้องหลัง
พอ build เร็วถึงระดับที่ “เร็วพอแล้ว” ก็จะหมด แรงจูงใจทางธุรกิจ ที่จะลงมือทำงานยาก ๆ เพื่อทำความเข้าใจโค้ดเบส
จากนี้ก็เหลือแค่เส้นทางสู่โค้ดเบสขนาด 1 พันล้านบรรทัดเท่านั้น
จากคำอธิบายมันฟังดูเหมือนทำมาสำหรับ Android source โดยเฉพาะ เลยสงสัยว่าทำไมถึงเป็นแบบนั้น และใช้กับโค้ดเบสอื่นได้หรือไม่