dwarfs
v0.10.2
D การให้ความรู้ W arp-speed ระบบ F ile S แบบ อ่านอย่าง เดียว ขั้นสูง
ระบบไฟล์แบบอ่านอย่างเดียวแบบบีบอัดสูงที่รวดเร็วสำหรับ Linux และ Windows
DwarFS คือระบบไฟล์แบบอ่านอย่างเดียวโดยมุ่งเน้นที่การบรรลุ อัตราส่วนการบีบอัดที่สูงมาก โดยเฉพาะอย่างยิ่งสำหรับข้อมูลที่ซ้ำซ้อนมาก
นี่อาจฟังดูไม่น่าตื่นเต้นนัก เพราะหากซ้ำซ้อน ก็ ควรจะ บีบอัดได้ดี อย่างไรก็ตาม ฉันพบว่าระบบไฟล์บีบอัดแบบอ่านอย่างเดียวอื่นๆ ทำงานได้ไม่ดีนักในการใช้ประโยชน์จากความซ้ำซ้อนนี้ ดูที่นี่สำหรับการเปรียบเทียบกับระบบไฟล์บีบอัดอื่นๆ
DwarFS ไม่ยอมประนีประนอมกับความเร็ว และสำหรับกรณีการใช้งานของฉัน ฉันพบว่ามันเทียบเท่าหรือทำงานได้ดีกว่า SquashFS สำหรับกรณีการใช้งานหลักของฉัน การบีบอัด DwarFS มีลำดับความสำคัญที่ดีกว่าการบีบอัด SquashFS การสร้างระบบไฟล์เร็วกว่า 6 เท่า โดยทั่วไปจะเข้าถึงไฟล์บน DwarFS ได้เร็วกว่า และใช้ทรัพยากร CPU น้อยกว่า
เพื่อให้คุณเข้าใจว่า DwarFS มีความสามารถอะไรบ้าง ต่อไปนี้คือการเปรียบเทียบโดยย่อของ DwarFS และ SquashFS บนชุดไฟล์วิดีโอที่มีขนาดรวม 39 GiB จุดหักมุมคือไฟล์วิดีโอแต่ละไฟล์มีไฟล์พี่น้องสองไฟล์ที่มีชุดสตรีมเสียงต่างกัน (นี่เป็นกรณีการใช้งานจริง) ดังนั้นจึงมีความซ้ำซ้อนทั้งในข้อมูลวิดีโอและเสียง แต่เนื่องจากสตรีมมีการแทรกสลับกันและบล็อกที่เหมือนกันมักจะอยู่ห่างกันมาก จึงเป็นเรื่องยากที่จะใช้ความซ้ำซ้อนนั้นในการบีบอัด โดยพื้นฐานแล้ว SquashFS ล้มเหลวในการบีบอัดข้อมูลต้นฉบับเลย ในขณะที่ DwarFS สามารถลดขนาดได้เกือบ 3 เท่า ซึ่งใกล้เคียงกับค่าสูงสุดทางทฤษฎี:
$ du -hs dwarfs-video-test
39G dwarfs-video-test
$ ls -lh dwarfs-video-test.*fs
-rw-r--r-- 1 mhx users 14G Jul 2 13:01 dwarfs-video-test.dwarfs
-rw-r--r-- 1 mhx users 39G Jul 12 09:41 dwarfs-video-test.squashfs
นอกจากนี้ เมื่อติดตั้งอิมเมจ SquashFS และทำการทดสอบทรูพุตการอ่านแบบสุ่มโดยใช้ fio-3.34 ทั้ง squashfuse และ squashfuse_ll จะอยู่ที่ประมาณ 230 MiB/s:
$ fio --readonly --rw=randread --name=randread --bs=64k --direct=1
--opendir=mnt --numjobs=4 --ioengine=libaio --iodepth=32
--group_reporting --runtime=60 --time_based
[...]
READ: bw=230MiB/s (241MB/s), 230MiB/s-230MiB/s (241MB/s-241MB/s), io=13.5GiB (14.5GB), run=60004-60004msec
ในการเปรียบเทียบ DwarFS สามารถรักษา อัตราการอ่านแบบสุ่มไว้ที่ 20 GiB/s :
READ: bw=20.2GiB/s (21.7GB/s), 20.2GiB/s-20.2GiB/s (21.7GB/s-21.7GB/s), io=1212GiB (1301GB), run=60001-60001msec
คุณสมบัติที่โดดเด่นของ DwarFS คือ:
การจัดกลุ่มไฟล์ตามความคล้ายคลึงกันโดยใช้ฟังก์ชันแฮชความคล้ายคลึงกัน ทำให้ง่ายต่อการใช้ประโยชน์จากความซ้ำซ้อนข้ามขอบเขตไฟล์
การวิเคราะห์การแบ่งกลุ่มระหว่างบล็อกระบบไฟล์เพื่อลดขนาดของระบบไฟล์ที่ไม่มีการบีบอัด สิ่งนี้จะช่วยประหยัดหน่วยความจำเมื่อใช้ระบบไฟล์ที่บีบอัด และอาจอนุญาตให้มีอัตราการเข้าถึงแคชที่สูงขึ้น เนื่องจากสามารถเก็บข้อมูลไว้ในแคชได้มากขึ้น
กรอบการจัดหมวดหมู่เพื่อจัดหมวดหมู่ไฟล์หรือแม้แต่ส่วนของไฟล์ จากนั้นประมวลผลแต่ละหมวดหมู่ที่แตกต่างกัน ตัวอย่างเช่น ช่วยให้คุณไม่ต้องเสียเวลาในการบีบอัดไฟล์ที่ไม่สามารถบีบอัดได้ หรือบีบอัดข้อมูลเสียง PCM โดยใช้การบีบอัด FLAC
การใช้งานแบบมัลติเธรดสูง ทั้งเครื่องมือสร้างระบบไฟล์และไดรเวอร์ FUSE สามารถใช้ประโยชน์จากคอร์จำนวนมากในระบบของคุณได้
ฉันเริ่มทำงานกับ DwarFS ในปี 2013 และกรณีการใช้งานหลักของฉันและแรงจูงใจหลักคือฉันมี Perl หลายร้อยเวอร์ชันที่ใช้พื้นที่ดิสก์ประมาณ 30 กิกะไบต์ และฉันไม่เต็มใจที่จะใช้เงินหนักกว่า 10% ขับรถเก็บไว้เมื่อฉันต้องการมัน
จนถึงตอนนั้น ฉันเคยใช้ Cromfs เพื่อบีบมันให้มีขนาดที่สามารถจัดการได้ อย่างไรก็ตาม ฉันรู้สึกรำคาญมากขึ้นเรื่อยๆ เมื่อต้องสร้างอิมเมจระบบไฟล์ และที่แย่ไปกว่านั้นคือ บ่อยครั้งกว่านั้นระบบล่มหลังจากผ่านไปประมาณหนึ่งชั่วโมงหรือประมาณนั้น
เห็นได้ชัดว่าฉันได้ดู SquashFS ด้วย แต่ไม่เคยเข้าใกล้อัตราการบีบอัดของ Cromfs เลย
เพียงอย่างเดียวไม่เพียงพอที่จะทำให้ฉันเขียน DwarFS ได้ แต่ในขณะเดียวกัน ฉันก็ค่อนข้างหมกมุ่นอยู่กับการพัฒนาล่าสุดและคุณสมบัติต่างๆ ของมาตรฐาน C++ ที่ใหม่กว่า และต้องการให้โปรเจ็กต์งานอดิเรก C++ ทำงานจริงๆ นอกจากนี้ฉันอยากจะทำอะไรบางอย่างกับ FUSE มาระยะหนึ่งแล้ว สุดท้ายแต่ไม่ท้ายสุด ฉันคิดเกี่ยวกับปัญหาของระบบไฟล์บีบอัดมาระยะหนึ่งแล้ว และมีแนวคิดบางอย่างที่ฉันอยากลองอย่างแน่นอน
โค้ดส่วนใหญ่เขียนขึ้นในปี 2013 จากนั้นฉันก็ทำการล้างข้อมูล แก้ไขจุดบกพร่อง และรีแฟกเตอร์บ้างเป็นครั้งคราว แต่ฉันไม่เคยได้รับมันเลยจริงๆ ในระดับที่ฉันรู้สึกมีความสุขที่จะปล่อยมันออกมา มันอึดอัดเกินไปที่จะสร้างโดยอาศัยไลบรารีโง่ ๆ ของ Facebook (ค่อนข้างยอดเยี่ยม) และไม่มีเอกสารประกอบใด ๆ
การขุดโครงการอีกครั้งในปีนี้ สิ่งต่างๆ ไม่ได้ดูน่ากลัวเหมือนเมื่อก่อน ตอนนี้ Folly สร้างด้วย CMake ดังนั้นฉันจึงดึงมันเข้ามาเป็นโมดูลย่อย การขึ้นต่อกันอื่นๆ ส่วนใหญ่สามารถได้รับจากแพ็คเกจที่ควรมีให้ใช้งานอย่างกว้างขวาง และฉันได้เขียนเอกสารพื้นฐานบางอย่างเช่นกัน
โดยปกติแล้ว DwarFS ควรสร้างได้ดีโดยมีการเปลี่ยนแปลงเล็กน้อยตั้งแต่เริ่มต้น หากไม่เป็นเช่นนั้น โปรดแจ้งปัญหา ฉันได้ตั้งค่างาน CI โดยใช้อิมเมจ Docker สำหรับ Ubuntu (22.04 และ 24.04), Fedora Rawhide และ Arch ที่สามารถช่วยในการกำหนดชุดการพึ่งพาที่ทันสมัย โปรดทราบว่าการสร้างจาก release tarball ต้องการการพึ่งพาน้อยกว่าการสร้างจากพื้นที่เก็บข้อมูล git โดยเฉพาะอย่างยิ่งเครื่องมือ ronn เช่นเดียวกับ Python และโมดูล mistletoe Python นั้นไม่จำเป็นเมื่อสร้างจาก release tarball
มีบางสิ่งที่ควรทราบ:
มีแนวโน้มที่จะพยายามแยกกลุ่มไลบรารี fly และ fbtthrift ที่รวมไว้เป็นโมดูลย่อยและสร้างขึ้นพร้อมกับ DwarFS แม้ว่าฉันจะเห็นด้วยกับความรู้สึกนี้ แต่น่าเสียดายที่มันเป็นความคิดที่ไม่ดี นอกจากข้อเท็จจริงที่ว่าความโง่เขลาไม่ได้อ้างสิทธิ์ใด ๆ เกี่ยวกับความเสถียรของ ABI (เช่น คุณไม่สามารถเชื่อมโยงไบนารีที่สร้างขึ้นจากความโง่เขลาเวอร์ชันหนึ่งกับเวอร์ชันอื่นแบบไดนามิกได้) เป็นไปไม่ได้ด้วยซ้ำที่จะเชื่อมโยงกับไลบรารีโง่ ๆ ที่สร้างด้วยการคอมไพล์ที่แตกต่างกันอย่างปลอดภัย ตัวเลือก แม้แต่ความแตกต่างเล็กน้อย เช่น เวอร์ชันมาตรฐาน C++ ก็อาจทำให้เกิดข้อผิดพลาดรันไทม์ได้ ดูปัญหานี้สำหรับรายละเอียด ในปัจจุบัน ยังเป็นไปไม่ได้เลยที่จะใช้เวอร์ชันภายนอกของ fly/fbthrift เนื่องจาก DwarFS กำลังสร้างชุดย่อยขั้นต่ำของทั้งสองไลบรารี สิ่งเหล่านี้รวมอยู่ในไลบรารี dwarfs_common และมีการใช้เป็นการภายในอย่างเคร่งครัด กล่าวคือ ไม่ต้องใช้ส่วนหัว folly หรือ fbtthrif ใดเพื่อสร้างเทียบกับไลบรารีของ DwarFS
ปัญหาที่คล้ายกันอาจเกิดขึ้นได้เมื่อใช้ GoogleTest เวอร์ชันที่ระบบติดตั้ง GoogleTest แนะนำให้ดาวน์โหลดเป็นส่วนหนึ่งของบิลด์ อย่างไรก็ตาม คุณสามารถใช้เวอร์ชันที่ระบบติดตั้งได้โดยส่ง -DPREFER_SYSTEM_GTEST=ON ไปที่การโทร cmake ใช้ความเสี่ยงของคุณเอง
สำหรับไลบรารีรวมอื่นๆ (ได้แก่ fmt , parallel-hashmap , range-v3 ) เวอร์ชันที่ระบบติดตั้งจะถูกใช้ตราบเท่าที่เป็นไปตามเวอร์ชันขั้นต่ำที่ต้องการ มิฉะนั้น ระบบจะดึงข้อมูลเวอร์ชันที่ต้องการระหว่างการสร้าง
แต่ละรุ่นมีไบนารีที่สร้างไว้ล่วงหน้าและเชื่อมโยงแบบคงที่สำหรับ Linux-x86_64 , Linux-aarch64 และ Windows-AMD64 พร้อมให้ดาวน์โหลด สิ่งเหล่านี้ ควร ทำงานโดยไม่ต้องพึ่งพาใดๆ และอาจมีประโยชน์โดยเฉพาะอย่างยิ่งในการกระจายแบบเก่าซึ่งคุณไม่สามารถสร้างเครื่องมือจากแหล่งที่มาได้อย่างง่ายดาย
นอกจาก tarball ไบนารีแล้ว ยังมี ไบนารีสากล สำหรับแต่ละสถาปัตยกรรมอีกด้วย ไบนารีสากลเหล่านี้มีเครื่องมือ ทั้งหมด ( mkdwarfs , dwarfsck , dwarfsextract และไดรเวอร์ dwarfs FUSE) ในปฏิบัติการเดียว ไฟล์ปฏิบัติการเหล่านี้ได้รับการบีบอัดโดยใช้ upx ดังนั้นจึงมีขนาดเล็กกว่าเครื่องมือแต่ละตัวรวมกันมาก อย่างไรก็ตาม มันยังหมายความว่าไบนารีจะต้องถูกคลายการบีบอัดทุกครั้งที่รัน ซึ่งอาจมีค่าใช้จ่ายจำนวนมาก หากนั่นเป็นปัญหา คุณสามารถยึดติดกับไบนารี่ "คลาสสิก" แต่ละตัว หรือคุณสามารถขยายขนาดไบนารีสากลได้ เช่น:
upx -d dwarfs-universal-0.7.0-Linux-aarch64
ไบนารีสากลสามารถเรียกใช้ผ่านลิงก์สัญลักษณ์ที่ตั้งชื่อตามเครื่องมือที่เหมาะสม เช่น:
$ ln -s dwarfs-universal-0.7.0-Linux-aarch64 mkdwarfs
$ ./mkdwarfs --help
นอกจากนี้ยังใช้งานได้บน Windows หากระบบไฟล์รองรับลิงก์สัญลักษณ์:
> mklink mkdwarfs.exe dwarfs-universal-0.7.0-Windows-AMD64.exe
> .mkdwarfs.exe --help
หรือคุณสามารถเลือกเครื่องมือโดยส่ง --tool=<name> เป็นอาร์กิวเมนต์แรกบนบรรทัดคำสั่ง:
> .dwarfs-universal-0.7.0-Windows-AMD64.exe --tool=mkdwarfs --help
โปรดทราบว่าเช่นเดียวกับไบนารี Windows dwarfs.exe ไบนารี Windows สากลจะขึ้นอยู่กับ winfsp-x64.dll จากโครงการ WinFsp อย่างไรก็ตาม สำหรับไบนารี่สากล DLL จะถูกโหลดอย่างเกียจคร้าน ดังนั้นคุณยังคงสามารถใช้เครื่องมืออื่นๆ ทั้งหมดได้โดยไม่ต้องใช้ DLL ดูส่วนการสนับสนุน Windows สำหรับรายละเอียดเพิ่มเติม
DwarFS ใช้ CMake เป็นเครื่องมือสร้าง
มันใช้ทั้ง Boost และ Folly แม้ว่าอย่างหลังจะรวมเป็นโมดูลย่อยเนื่องจากมีการแจกแจงเพียงไม่กี่รายการเท่านั้นที่เสนอแพ็คเกจสำหรับมัน ความโง่เขลานั้นมีการขึ้นต่อกันหลายอย่าง ดังนั้นโปรดตรวจสอบที่นี่เพื่อดูรายการล่าสุด
นอกจากนี้ยังใช้ Facebook Thrift โดยเฉพาะไลบรารี frozen เพื่อจัดเก็บข้อมูลเมตาในรูปแบบที่ประหยัดพื้นที่สูง สามารถแมปหน่วยความจำได้ และมีรูปแบบที่กำหนดไว้อย่างดี มันยังรวมไว้เป็นโมดูลย่อยด้วย และเราสร้างเฉพาะคอมไพเลอร์และไลบรารี่ที่เล็กลงมากซึ่งมีเพียงพอให้ DwarFS ทำงานได้
นอกเหนือจากนั้น DwarFS จริงๆ แล้วขึ้นอยู่กับ FUSE3 และชุดของไลบรารีการบีบอัดที่ Folly ขึ้นอยู่กับอยู่แล้ว (ได้แก่ lz4, zstd และ liblzma)
การพึ่งพา googletest จะได้รับการแก้ไขโดยอัตโนมัติหากคุณสร้างด้วยการทดสอบ
จุดเริ่มต้นที่ดีสำหรับระบบที่ใช้ apt น่าจะเป็น:
$ apt install
gcc
g++
clang
git
ccache
ninja-build
cmake
make
bison
flex
fuse3
pkg-config
binutils-dev
libacl1-dev
libarchive-dev
libbenchmark-dev
libboost-chrono-dev
libboost-context-dev
libboost-filesystem-dev
libboost-iostreams-dev
libboost-program-options-dev
libboost-regex-dev
libboost-system-dev
libboost-thread-dev
libbrotli-dev
libevent-dev
libhowardhinnant-date-dev
libjemalloc-dev
libdouble-conversion-dev
libiberty-dev
liblz4-dev
liblzma-dev
libzstd-dev
libxxhash-dev
libmagic-dev
libparallel-hashmap-dev
librange-v3-dev
libssl-dev
libunwind-dev
libdwarf-dev
libelf-dev
libfmt-dev
libfuse3-dev
libgoogle-glog-dev
libutfcpp-dev
libflac++-dev
nlohmann-json3-dev
โปรดทราบว่าเมื่อสร้างด้วย gcc ระดับการปรับให้เหมาะสมที่สุดจะถูกตั้งค่าเป็น -O2 แทนที่จะเป็นค่าเริ่มต้น CMake เป็น -O3 สำหรับรุ่น release อย่างน้อยสำหรับเวอร์ชันสูงถึง gcc-10 บิลด์ -O3 จะช้ากว่าบิลด์ที่มี -O2 ถึง 70%
ขั้นแรก ให้แตกไฟล์เก็บถาวรที่เผยแพร่:
$ tar xvf dwarfs-x.y.z.tar.xz
$ cd dwarfs-x.y.z
หรือคุณสามารถโคลนพื้นที่เก็บข้อมูล git ได้ แต่โปรดทราบว่าสิ่งนี้มีการพึ่งพามากกว่าและการสร้างอาจใช้เวลานานกว่าเนื่องจากไฟล์เก็บถาวร release มาพร้อมกับไฟล์ส่วนใหญ่ที่สร้างขึ้นอัตโนมัติซึ่งจะต้องสร้างขึ้นเมื่อสร้างจากพื้นที่เก็บข้อมูล:
$ git clone --recurse-submodules https://github.com/mhx/dwarfs
$ cd dwarfs
เมื่อติดตั้งการขึ้นต่อกันทั้งหมดแล้ว คุณสามารถสร้าง DwarFS ได้โดยใช้:
$ mkdir build
$ cd build
$ cmake .. -GNinja -DWITH_TESTS=ON
$ ninja
จากนั้นคุณสามารถรันการทดสอบด้วย:
$ ctest -j
ไบนารีทั้งหมดใช้ jemalloc เป็นตัวจัดสรรหน่วยความจำตามค่าเริ่มต้น เนื่องจากโดยทั่วไปจะใช้หน่วยความจำระบบน้อยกว่ามากเมื่อเทียบกับตัวจัดสรร glibc หรือ tcmalloc หากต้องการปิดใช้งาน jemalloc ให้ส่ง -DUSE_JEMALLOC=0 บนบรรทัดรับคำสั่ง cmake
นอกจากนี้ยังสามารถสร้าง/ติดตั้งไลบรารี เครื่องมือ และไดรเวอร์ FUSE ของ DwarFS ได้อย่างอิสระ สิ่งนี้น่าสนใจเป็นส่วนใหญ่เมื่อทำการบรรจุ DwarFS โปรดทราบว่าเครื่องมือและไดรเวอร์ FUSE จำเป็นต้องมีไลบรารีที่สร้างขึ้นหรือติดตั้งไว้แล้ว หากต้องการสร้างเฉพาะไลบรารี ให้ใช้:
$ cmake .. -GNinja -DWITH_TESTS=ON -DWITH_LIBDWARFS=ON -DWITH_TOOLS=OFF -DWITH_FUSE_DRIVER=OFF
เมื่อไลบรารีได้รับการทดสอบและติดตั้งแล้ว คุณสามารถสร้างเครื่องมือ (เช่น mkdwarfs , dwarfsck , dwarfsextract ) โดยใช้:
$ cmake .. -GNinja -DWITH_TESTS=ON -DWITH_LIBDWARFS=OFF -DWITH_TOOLS=ON -DWITH_FUSE_DRIVER=OFF
หากต้องการสร้างไดรเวอร์ FUSE ให้ใช้:
$ cmake .. -GNinja -DWITH_TESTS=ON -DWITH_LIBDWARFS=OFF -DWITH_TOOLS=OFF -DWITH_FUSE_DRIVER=ON
การติดตั้งทำได้ง่ายเพียง:
$ sudo ninja install
แม้ว่าคุณจะไม่ต้องติดตั้งเครื่องมือเพื่อเล่นกับมันก็ตาม
ความพยายามที่จะสร้างไบนารีที่เชื่อมโยงแบบคงที่นั้นไม่สนับสนุนอย่างมากและไม่ได้รับการสนับสนุนอย่างเป็นทางการ ดังที่ได้กล่าวไปแล้ว ต่อไปนี้เป็นวิธีการตั้งค่าสภาพแวดล้อมที่คุณ อาจสามารถ สร้างไบนารีแบบคงที่ได้
สิ่งนี้ได้รับการทดสอบกับ ubuntu-22.04-live-server-amd64.iso ขั้นแรก ให้ติดตั้งแพ็คเกจทั้งหมดที่แสดงการขึ้นต่อกันด้านบน ติดตั้งด้วย:
$ apt install ccache ninja libacl1-dev
ccache และ ninja เป็นทางเลือก แต่ช่วยในการคอมไพล์ที่รวดเร็ว
คุณจะต้องสร้างและติดตั้งเวอร์ชันคงที่ของไลบรารีบางตัว เช่น libarchive และ libmagic สำหรับ Ubuntu ทั้งนี้ขึ้นอยู่กับการแจกจ่ายของคุณ:
$ wget https://github.com/libarchive/libarchive/releases/download/v3.6.2/libarchive-3.6.2.tar.xz
$ tar xf libarchive-3.6.2.tar.xz && cd libarchive-3.6.2
$ ./configure --prefix=/opt/static-libs --without-iconv --without-xml2 --without-expat
$ make && sudo make install
$ wget ftp://ftp.astron.com/pub/file/file-5.44.tar.gz
$ tar xf file-5.44.tar.gz && cd file-5.44
$ ./configure --prefix=/opt/static-libs --enable-static=yes --enable-shared=no
$ make && make install
แค่นั้นแหละ! ตอนนี้คุณสามารถลองสร้างไบนารีแบบคงที่สำหรับ DwarFS:
$ git clone --recurse-submodules https://github.com/mhx/dwarfs
$ cd dwarfs && mkdir build && cd build
$ cmake .. -GNinja -DWITH_TESTS=ON -DSTATIC_BUILD_DO_NOT_USE=ON
-DSTATIC_BUILD_EXTRA_PREFIX=/opt/static-libs
$ ninja
$ ninja test
โปรดดูหน้าคู่มือสำหรับ mkdwarfs, dwarfs, dwarfsck และ dwarfsextract คุณยังสามารถเข้าถึงหน้าคู่มือได้โดยใช้ตัวเลือก --man สำหรับแต่ละไบนารี เช่น:
$ mkdwarfs --man
หน้าคู่มือคนแคระยังแสดงตัวอย่างสำหรับการตั้งค่า DwarFS ด้วยการซ้อนทับเพื่อสร้างระบบไฟล์ที่เขียนได้ซึ่งเมานต์อยู่ด้านบนของอิมเมจ DwarFS แบบอ่านอย่างเดียว
คำอธิบายของรูปแบบระบบไฟล์ DwarFS สามารถพบได้ในรูปแบบแคระ
ภาพรวมระดับสูงของการดำเนินการภายในของ mkdwarfs แสดงในแผนภาพลำดับนี้
การใช้ไลบรารี DwarFS ควรตรงไปตรงมาหากคุณใช้ CMake เพื่อสร้างโครงการของคุณ เพื่อการเริ่มต้นอย่างรวดเร็ว โปรดดูโค้ดตัวอย่างที่ใช้ไลบรารีเพื่อพิมพ์ข้อมูลเกี่ยวกับอิมเมจ DwarFS (เช่น dwarfsck ) หรือแยกออกมา (เช่น dwarfsextract )
มีห้องสมุดส่วนตัวห้าแห่ง:
dwarfs_common มีโค้ดทั่วไปที่ไลบรารีอื่นๆ ต้องการ อินเทอร์เฟซถูกกำหนดไว้ใน dwarfs/
dwarfs_reader มีโค้ดทั้งหมดที่จำเป็นในการอ่านข้อมูลจากอิมเมจ DwarFS อินเทอร์เฟซถูกกำหนดไว้ใน dwarfs/reader/
dwarfs_extractor มีโค้ดที่จำเป็นสำหรับการแยกอิมเมจ DwarFS โดยใช้ libarchive อินเทอร์เฟซถูกกำหนดไว้ใน dwarfs/utility/filesystem_extractor.h
dwarfs_writer มีโค้ดที่จำเป็นในการสร้างอิมเมจ DwarFS อินเทอร์เฟซถูกกำหนดไว้ใน dwarfs/writer/
dwarfs_rewrite มีโค้ดสำหรับเขียนอิมเมจ DwarFS ใหม่ อินเทอร์เฟซถูกกำหนดไว้ใน dwarfs/utility/rewrite_filesystem.h
ส่วนหัวในโฟลเดอร์ย่อย internal สามารถเข้าถึงได้เฉพาะในขณะที่สร้างและจะไม่ได้รับการติดตั้ง เช่นเดียวกับโฟลเดอร์ย่อย tool
API ตัวอ่านและตัวแยกข้อมูลควรมีความเสถียรพอสมควร API ตัวเขียนมีแนวโน้มที่จะเปลี่ยนแปลง อย่างไรก็ตาม โปรดทราบว่าไม่มีการรับประกันความเสถียรของ API ก่อนที่โปรเจ็กต์นี้จะถึงเวอร์ชัน 1.0.0
การสนับสนุนระบบปฏิบัติการ Windows อยู่ระหว่างการทดลอง หลังจากทำงานค่อนข้างมากในโลก Unix โดยเฉพาะในช่วงสองทศวรรษที่ผ่านมา ประสบการณ์ของฉันในการพัฒนา Windows ค่อนข้างจำกัด และฉันคาดหวังว่าจะมีข้อบกพร่องและขอบหยาบในโค้ด Windows อย่างแน่นอน
ไดรเวอร์ระบบไฟล์ DwarFS เวอร์ชัน Windows อาศัยโปรเจ็กต์ WinFsp ที่ยอดเยี่ยม และไดรเวอร์ dwarfs.exe จะต้องค้นพบ winfsp-x64.dll ได้
เครื่องมือต่างๆ ควรมีลักษณะการทำงานค่อนข้างเหมือนกันไม่ว่าคุณจะใช้งานบน Linux หรือ Windows อิมเมจระบบไฟล์สามารถคัดลอกระหว่าง Linux และ Windows และรูปภาพที่สร้างบนระบบปฏิบัติการหนึ่งควรทำงานได้ดีบนอีกระบบปฏิบัติการ
มีบางสิ่งที่ควรค่าแก่การชี้ให้เห็น:
DwarFS รองรับทั้งฮาร์ดลิงก์และซิมลิงก์บน Windows เช่นเดียวกับบน Linux อย่างไรก็ตาม การสร้างฮาร์ดลิงก์และซิมลิงก์ดูเหมือนจะต้องใช้สิทธิ์ผู้ดูแลระบบบน Windows ดังนั้น หากคุณต้องการแยกอิมเมจ DwarFS ที่มีลิงก์บางประเภท คุณอาจพบข้อผิดพลาดหากคุณไม่มีสิทธิ์ที่ถูกต้อง
เนื่องจากปัญหาใน WinFsp ขณะนี้ Symlink ไม่สามารถชี้ไปนอกระบบไฟล์ที่เมาท์ได้ นอกจากนี้ เนื่องจากปัญหาอื่นใน WinFsp ลิงก์สัญลักษณ์ที่มีอักษรระบุไดรฟ์จะปรากฏขึ้นพร้อมกับเส้นทางเป้าหมายที่เสียหาย
ไดรเวอร์ DwarFS บน Windows รายงานจำนวนฮาร์ดลิงก์ผ่าน API อย่างถูกต้อง แต่ในปัจจุบันจำนวนเหล่านี้ไม่ได้แพร่กระจายไปยังเลเยอร์ระบบไฟล์ Windows อย่างถูกต้อง อาจเป็นเพราะปัญหาใน WinFsp
เมื่อติดตั้งอิมเมจ DwarFS บน Windows จะต้องไม่มีจุดเมานท์ สิ่งนี้แตกต่างจาก Linux ซึ่งต้องมีจุดเมานท์อยู่จริง นอกจากนี้ยังสามารถติดตั้งอิมเมจ DwarFS เป็นอักษรระบุไดรฟ์ได้ เช่น
dwarfs.exe image.คนแคระ Z:
กฎการกรองสำหรับ mkdwarfs ต้องใช้ตัวแยกเส้นทาง Unix เสมอ ไม่ว่าจะทำงานบน Windows หรือ Linux ก็ตาม
การสร้างบน Windows นั้นไม่ซับซ้อนเกินไป ต้องขอบคุณ vcpkg คุณจะต้องติดตั้ง:
Visual Studio และคอมไพเลอร์ MSVC C/C++
คอมไพล์
ซีเมค
นินจา
WinFsp
คาดว่าจะติดตั้ง WinFsp ใน C:Program Files (x86)WinFsp ; หากไม่เป็นเช่นนั้น คุณจะต้องตั้งค่า WINFSP_PATH เมื่อเรียกใช้ CMake ผ่าน cmake/win.bat
ตอนนี้คุณต้องโคลน vcpkg และ dwarfs :
> cd %HOMEPATH%
> mkdir git
> cd git
> git clone https://github.com/Microsoft/vcpkg.git
> git clone https://github.com/mhx/dwarfs
จากนั้นบูตสแตรป vcpkg :
> .vcpkgbootstrap-vcpkg.bat
และสร้าง DwarFS:
> cd dwarfs
> mkdir build
> cd build
> ..cmakewin.bat
> ninja
เมื่อเสร็จแล้วคุณควรจะสามารถดำเนินการทดสอบได้ ตั้งค่า CTEST_PARALLEL_LEVEL ตามจำนวนคอร์ CPU ในเครื่องของคุณ
> set CTEST_PARALLEL_LEVEL=10
> ninja test
ไลบรารีและเครื่องมือ DwarFS ( mkdwarfs , dwarfsck , dwarfsextract ) พร้อมใช้งานแล้วจาก Homebrew:
$ brew install dwarfs
$ brew test dwarfs
ไดรเวอร์ระบบไฟล์ DwarFS เวอร์ชัน macOS อาศัยโปรเจ็กต์ macFUSE ที่ยอดเยี่ยม คุณจะต้องสร้างไดรเวอร์ DwarFS FUSE ด้วยตนเองจนกว่าจะมีการเพิ่มสูตร
การสร้างบน macOS ควรจะค่อนข้างตรงไปตรงมา:
ติดตั้งโฮมบรูว์
ใช้ Homebrew เพื่อติดตั้งการขึ้นต่อกันที่จำเป็น:
$ brew install cmake ninja macfuse brotli howard-hinnant-date double-conversion
fmt glog libarchive libevent flac openssl nlohmann-json pkg-config
range-v3 utf8cpp xxhash boost zstd
เมื่อติดตั้ง macFUSE เป็นครั้งแรก คุณจะต้องอนุญาตซอฟต์แวร์ใน System Preferences / Privacy & Security อย่างชัดเจน มีแนวโน้มค่อนข้างมากที่คุณจะต้องรีบูตหลังจากนี้
ดาวน์โหลด tarball release จากหน้า releases และแตกไฟล์:
$ wget https://github.com/mhx/dwarfs/releases/download/v0.10.0/dwarfs-0.10.0.tar.xz
$ tar xf dwarfs-0.10.0.tar.xz
$ cmake --fresh -B dwarfs-build -S dwarfs-0.10.0 -GNinja -DWITH_TESTS=ON
$ cmake --build dwarfs-build
$ ctest --test-dir dwarfs-build -j
macfuse จาก brew install และใช้คำสั่งต่อไปนี้แทนคำสั่ง cmake แรกด้านบน: $ cmake --fresh -B dwarfs-build -S dwarfs-0.10.0 -GNinja -DWITH_TESTS=ON -DWITH_FUSE_DRIVER=OFF
$ cmake --fresh -B dwarfs-build -S dwarfs-0.10.0 -GNinja -DWITH_TESTS=ON -DWITH_LIBDWARFS=OFF -DWITH_TOOLS=OFF
$ sudo cmake --install dwarfs-build
แค่นั้นแหละ!
การถ่ายภาพดาราศาสตร์สามารถสร้างข้อมูลภาพดิบจำนวนมหาศาลได้ ในคืนเดียว ไม่น่าจะจบลงด้วยข้อมูลจำนวนหลายสิบกิกะไบต์ สำหรับกล้องถ่ายภาพดาราศาสตร์โดยเฉพาะส่วนใหญ่ ข้อมูลนี้จะจบลงในรูปแบบของภาพ FITS โดยปกติแล้วสิ่งเหล่านี้จะไม่มีการบีบอัด บีบอัดได้ไม่ดีนักด้วยอัลกอริธึมการบีบอัดมาตรฐาน และแม้ว่าจะมีรูปแบบ FITS ที่บีบอัดบางรูปแบบ แต่ก็ไม่ได้รับการสนับสนุนอย่างกว้างขวาง
รูปแบบการบีบอัดรูปแบบหนึ่ง (เรียกง่ายๆ ว่า "ข้าว") จะบีบอัดได้ดีพอสมควรและรวดเร็วมาก อย่างไรก็ตาม การใช้งานสำหรับ FITS แบบบีบอัดนั้นมีข้อเสียบางประการ ข้อเสียเปรียบที่รุนแรงที่สุดคือการบีบอัดข้อมูลได้ไม่ดีเท่าที่ควรสำหรับเซ็นเซอร์สีและเซ็นเซอร์ที่มีความละเอียดน้อยกว่า 16 บิต
DwarFS รองรับการบีบอัด ricepp (Rice++) ซึ่งต่อยอดมาจากแนวคิดพื้นฐานของการบีบอัดข้าว แต่มีการปรับปรุงบางประการ: โดยจะบีบอัดสีและรูปภาพที่มีความลึกบิตต่ำได้ดีขึ้นอย่างมาก และค้นหาวิธีแก้ปัญหาที่เหมาะสมที่สุดในระหว่างการบีบอัดแทนการอาศัยการวิเคราะห์พฤติกรรม .
ลองดูตัวอย่างการใช้ภาพ 129 ภาพ (มืด เรียบ และสว่าง) ที่ถ่ายด้วยกล้อง ASI1600MM แต่ละภาพมีขนาด 32 MiB ดังนั้นข้อมูลทั้งหมด 4 GiB การบีบอัดข้อมูลเหล่านี้ด้วยเครื่องมือ fpack มาตรฐานจะใช้เวลาประมาณ 16.6 วินาที และได้ขนาดเอาต์พุตรวม 2.2 GiB:
$ time fpack */*.fit */*/*.fit
user 14.992
system 1.592
total 16.616
$ find . -name '*.fz' -print0 | xargs -0 cat | wc -c
2369943360
อย่างไรก็ตาม สิ่งนี้จะทำให้คุณมีไฟล์ *.fz ซึ่งไม่ใช่ทุกแอปพลิเคชันที่สามารถอ่านได้จริง
เมื่อใช้ DwarFS นี่คือสิ่งที่เราได้รับ:
$ mkdwarfs -i ASI1600 -o asi1600-20.dwarfs -S 20 --categorize
I 08:47:47.459077 scanning "ASI1600"
I 08:47:47.491492 assigning directory and link inodes...
I 08:47:47.491560 waiting for background scanners...
I 08:47:47.675241 scanning CPU time: 1.051s
I 08:47:47.675271 finalizing file inodes...
I 08:47:47.675330 saved 0 B / 3.941 GiB in 0/258 duplicate files
I 08:47:47.675360 assigning device inodes...
I 08:47:47.675371 assigning pipe/socket inodes...
I 08:47:47.675381 building metadata...
I 08:47:47.675393 building blocks...
I 08:47:47.675398 saving names and symlinks...
I 08:47:47.675514 updating name and link indices...
I 08:47:47.675796 waiting for segmenting/blockifying to finish...
I 08:47:50.274285 total ordering CPU time: 616.3us
I 08:47:50.274329 total segmenting CPU time: 1.132s
I 08:47:50.279476 saving chunks...
I 08:47:50.279622 saving directories...
I 08:47:50.279674 saving shared files table...
I 08:47:50.280745 saving names table... [1.047ms]
I 08:47:50.280768 saving symlinks table... [743ns]
I 08:47:50.282031 waiting for compression to finish...
I 08:47:50.823924 compressed 3.941 GiB to 1.201 GiB (ratio=0.304825)
I 08:47:50.824280 compression CPU time: 17.92s
I 08:47:50.824316 filesystem created without errors [3.366s]
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
waiting for block compression to finish
5 dirs, 0/0 soft/hard links, 258/258 files, 0 other
original size: 3.941 GiB, hashed: 315.4 KiB (18 files, 0 B/s)
scanned: 3.941 GiB (258 files, 117.1 GiB/s), categorizing: 0 B/s
saved by deduplication: 0 B (0 files), saved by segmenting: 0 B
filesystem: 3.941 GiB in 4037 blocks (4550 chunks, 516/516 fragments, 258 inodes)
compressed filesystem: 4037 blocks/1.201 GiB written
ภายในเวลาไม่ถึง 3.4 วินาที จะบีบอัดข้อมูลลงเหลือ 1.2 GiB ซึ่งเกือบครึ่งหนึ่งของขนาดเอาต์พุต fpack
นอกจากจะช่วยประหยัดพื้นที่ดิสก์ได้มากแล้ว ยังมีประโยชน์เมื่อข้อมูลของคุณถูกจัดเก็บไว้ใน NAS อีกด้วย ต่อไปนี้คือการเปรียบเทียบชุดข้อมูลเดียวกันที่เข้าถึงผ่านการเชื่อมต่อเครือข่าย 1 Gb/s โดยใช้ข้อมูลดิบที่ไม่มีการบีบอัดก่อน:
find /mnt/ASI1600 -name '*.fit' -print0 | xargs -0 -P4 -n1 cat | dd of=/dev/null status=progress
4229012160 bytes (4.2 GB, 3.9 GiB) copied, 36.0455 s, 117 MB/s
และต่อไปใช้อิมเมจ DwarFS ในการแชร์เดียวกัน:
$ dwarfs /mnt/asi1600-20.dwarfs mnt
$ find mnt -name '*.fit' -print0 | xargs -0 -P4 -n1 cat | dd of=/dev/null status=progress
4229012160 bytes (4.2 GB, 3.9 GiB) copied, 14.3681 s, 294 MB/s
ซึ่งเร็วกว่าประมาณ 2.5 เท่า คุณน่าจะเห็นผลลัพธ์ที่คล้ายกันมากกับฮาร์ดไดรฟ์ภายนอกที่ช้า
ปัจจุบัน DwarFS ไม่มีความสามารถในตัวในการเพิ่มข้อมูลการกู้คืนลงในอิมเมจระบบไฟล์ อย่างไรก็ตาม เพื่อวัตถุประสงค์ในการเก็บถาวร เป็นความคิดที่ดีที่จะมีข้อมูลการกู้คืนดังกล่าวเพื่อให้สามารถซ่อมแซมอิมเมจที่เสียหายได้
โชคดีที่ค่อนข้างตรงไปตรงมาโดยใช้บางอย่างเช่น par2cmdline:
$ par2create -n1 asi1600-20.dwarfs
การดำเนินการนี้จะสร้างไฟล์เพิ่มเติมสองไฟล์ที่คุณสามารถวางไว้ข้างรูปภาพได้ (หรือในที่เก็บข้อมูลอื่น) เนื่องจากคุณจะต้องการไฟล์เหล่านั้นเฉพาะเมื่อ DwarFS ตรวจพบปัญหากับอิมเมจระบบไฟล์เท่านั้น มีปัญหาก็วิ่งได้
$ par2repair asi1600-20.dwarfs
ซึ่งมีแนวโน้มที่จะสามารถกู้คืนรูปภาพได้มากหากน้อยกว่า 5% (ซึ่งเป็นค่าเริ่มต้นที่ใช้โดย par2create ) ของรูปภาพเสียหาย
ขณะนี้ยังไม่รองรับแอตทริบิวต์เพิ่มเติม คุณลักษณะเพิ่มเติมใดๆ ที่จัดเก็บไว้ในระบบไฟล์ต้นทางจะไม่ถูกรักษาไว้ในขณะนี้เมื่อสร้างอิมเมจ DwarFS โดยใช้ mkdwarfs
ดังที่ได้กล่าวไปแล้ว รูทไอโหนดของอิมเมจ DwarFS ที่ติดตั้งอยู่ในปัจจุบันจะแสดงแอตทริบิวต์เพิ่มเติมหนึ่งหรือสองรายการบน Linux:
$ attr -l mnt
Attribute "dwarfs.driver.pid" has a 4 byte value for mnt
Attribute "dwarfs.driver.perfmon" has a 4849 byte value for mnt
แอ็ตทริบิวต์ dwarfs.driver.pid มีเพียง PID ของไดรเวอร์ DwarFS FUSE แอ็ตทริบิวต์ dwarfs.driver.perfmon ประกอบด้วยผลลัพธ์ปัจจุบันของการมอนิเตอร์ประสิทธิภาพ
นอกจากนี้ แต่ละไฟล์ปกติจะแสดงแอตทริบิวต์ dwarfs.inodeinfo พร้อมข้อมูลเกี่ยวกับไอโหนดพื้นฐาน:
$ attr -l "05 Disappear.caf"
Attribute "dwarfs.inodeinfo" has a 448 byte value for 05 Disappear.caf
แอตทริบิวต์ประกอบด้วยออบเจ็กต์ JSON พร้อมข้อมูลเกี่ยวกับไอโหนดพื้นฐาน:
$ attr -qg dwarfs.inodeinfo "05 Disappear.caf"
{
"chunks": [
{
"block": 2,
"category": "pcmaudio/metadata",
"offset": 270976,
"size": 4096
},
{
"block": 414,
"category": "pcmaudio/waveform",
"offset": 37594368,
"size": 29514492
},
{
"block": 419,
"category": "pcmaudio/waveform",
"offset": 0,
"size": 29385468
}
],
"gid": 100,
"mode": 33188,
"modestring": "----rw-r--r--",
"uid": 1000
}
สิ่งนี้มีประโยชน์ เช่น เพื่อตรวจสอบว่าไฟล์นั้นกระจายไปอย่างไรในหลาย ๆ บล็อก หรือหมวดหมู่ใดที่ได้รับการกำหนดให้กับไฟล์
การทดสอบ SquashFS, xz , lrzip , zpaq และ wimlib เสร็จสิ้นบน CPU Intel(R) Xeon(R) E-2286M 8 คอร์ @ 2.40GHz พร้อมด้วย RAM 64 GiB
การทดสอบ Cromfs เสร็จสิ้นด้วย DwarFS เวอร์ชันเก่าบน CPU Intel(R) Xeon(R) 6 คอร์ D-1528 @ 1.90GHz พร้อม RAM 64 GiB
การทดสอบ EROFS ดำเนินการโดยใช้ DwarFS v0.9.8 และ EROFS v1.7.1 บน Intel(R) Core(TM) i9-13900K พร้อมด้วย RAM 64 GiB
ระบบส่วนใหญ่ไม่ได้ใช้งานในระหว่างการทดสอบทั้งหมด
ไดเร็กทอรีต้นทางมี การติดตั้ง Perl ที่แตกต่างกัน 1,139 รายการ จาก 284 รุ่นที่แตกต่างกัน รวมเป็นข้อมูล 47.65 GiB ใน 1,927,501 ไฟล์ และ 330,733 ไดเร็กทอรี ไดเร็กทอรีต้นทางได้รับการแตกแพ็กใหม่จากไฟล์เก็บถาวร tar ไปยังพาร์ติชัน XFS บนไดรฟ์ NVME 970 EVO Plus 2TB ดังนั้นเนื้อหาส่วนใหญ่จึงมักถูกแคชไว้
ฉันใช้ประเภทการบีบอัดและระดับการบีบอัดเดียวกันสำหรับ SquashFS ซึ่งเป็นการตั้งค่าเริ่มต้นสำหรับ DwarFS:
$ time mksquashfs install perl-install.squashfs -comp zstd -Xcompression-level 22
Parallel mksquashfs: Using 16 processors
Creating 4.0 filesystem on perl-install-zstd.squashfs, block size 131072.
[=========================================================/] 2107401/2107401 100%
Exportable Squashfs 4.0 filesystem, zstd compressed, data block size 131072
compressed data, compressed metadata, compressed fragments,
compressed xattrs, compressed ids
duplicates are removed
Filesystem size 4637597.63 Kbytes (4528.90 Mbytes)
9.29% of uncompressed filesystem size (49922299.04 Kbytes)
Inode table size 19100802 bytes (18653.13 Kbytes)
26.06% of uncompressed inode table size (73307702 bytes)
Directory table size 19128340 bytes (18680.02 Kbytes)
46.28% of uncompressed directory table size (41335540 bytes)
Number of duplicate files found 1780387
Number of inodes 2255794
Number of files 1925061
Number of fragments 28713
Number of symbolic links 0
Number of device nodes 0
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 330733
Number of ids (unique uids + gids) 2
Number of uids 1
mhx (1000)
Number of gids 1
users (100)
real 32m54.713s
user 501m46.382s
sys 0m58.528s
สำหรับ DwarFS ฉันยังคงยึดตามค่าเริ่มต้น:
$ time mkdwarfs -i install -o perl-install.dwarfs
I 11:33:33.310931 scanning install
I 11:33:39.026712 waiting for background scanners...
I 11:33:50.681305 assigning directory and link inodes...
I 11:33:50.888441 finding duplicate files...
I 11:34:01.120800 saved 28.2 GiB / 47.65 GiB in 1782826/1927501 duplicate files
I 11:34:01.122608 waiting for inode scanners...
I 11:34:12.839065 assigning device inodes...
I 11:34:12.875520 assigning pipe/socket inodes...
I 11:34:12.910431 building metadata...
I 11:34:12.910524 building blocks...
I 11:34:12.910594 saving names and links...
I 11:34:12.910691 bloom filter size: 32 KiB
I 11:34:12.910760 ordering 144675 inodes using nilsimsa similarity...
I 11:34:12.915555 nilsimsa: depth=20000 (1000), limit=255
I 11:34:13.052525 updating name and link indices...
I 11:34:13.276233 pre-sorted index (660176 name, 366179 path lookups) [360.6ms]
I 11:35:44.039375 144675 inodes ordered [91.13s]
I 11:35:44.041427 waiting for segmenting/blockifying to finish...
I 11:37:38.823902 bloom filter reject rate: 96.017% (TPR=0.244%, lookups=4740563665)
I 11:37:38.823963 segmentation matches: good=454708, bad=6819, total=464247
I 11:37:38.824005 segmentation collisions: L1=0.008%, L2=0.000% [2233254 hashes]
I 11:37:38.824038 saving chunks...
I 11:37:38.860939 saving directories...
I 11:37:41.318747 waiting for compression to finish...
I 11:38:56.046809 compressed 47.65 GiB to 430.9 MiB (ratio=0.00883101)
I 11:38:56.304922 filesystem created without errors [323s]
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
waiting for block compression to finish
330733 dirs, 0/2440 soft/hard links, 1927501/1927501 files, 0 other
original size: 47.65 GiB, dedupe: 28.2 GiB (1782826 files), segment: 15.19 GiB
filesystem: 4.261 GiB in 273 blocks (319178 chunks, 144675/144675 inodes)
compressed filesystem: 273 blocks/430.9 MiB written [depth: 20000]
█████████████████████████████████████████████████████████████████████████████▏100% |
real 5m23.030s
user 78m7.554s
sys 1m47.968s
ดังนั้นในการเปรียบเทียบนี้ mkdwarfs เร็วกว่า mksquashfs มากกว่า 6 เท่า ทั้งในแง่ของเวลา CPU และเวลานาฬิกาแขวน
$ ll perl-install.*fs
-rw-r--r-- 1 mhx users 447230618 Mar 3 20:28 perl-install.dwarfs
-rw-r--r-- 1 mhx users 4748902400 Mar 3 20:10 perl-install.squashfs
ในแง่ของอัตราส่วนการบีบอัด ระบบไฟล์ DwarFS มีขนาดเล็กกว่าระบบไฟล์ SquashFS มากกว่า 10 เท่า ด้วย DwarFS เนื้อหาจะถูก บีบอัดลงเหลือน้อยกว่า 0.9% (!) ของขนาดดั้งเดิม อัตราการบีบอัดนี้จะพิจารณาเฉพาะข้อมูลที่จัดเก็บไว้ในไฟล์แต่ละไฟล์เท่านั้น ไม่ใช่พื้นที่ดิสก์จริงที่ใช้ บนระบบไฟล์ XFS ดั้งเดิม ตาม du โฟลเดอร์ต้นทางใช้ 52 GiB ดังนั้น อิมเมจ DwarFS จึงใช้พื้นที่ดั้งเดิมเพียง 0.8% เท่านั้น
นี่คือการเปรียบเทียบอื่นโดยใช้การบีบอัด lzma แทน zstd :
$ time mksquashfs install perl-install-lzma.squashfs -comp lzma
real 13m42.825s
user 205m40.851s
sys 3m29.088s
$ time mkdwarfs -i install -o perl-install-lzma.dwarfs -l9
real 3m43.937s
user 49m45.295s
sys 1m44.550s
$ ll perl-install-lzma.*fs
-rw-r--r-- 1 mhx users 315482627 Mar 3 21:23 perl-install-lzma.dwarfs
-rw-r--r-- 1 mhx users 3838406656 Mar 3 20:50 perl-install-lzma.squashfs
เห็นได้ชัดทันทีว่าการวิ่งเร็วขึ้นอย่างมาก และภาพที่ได้ก็มีขนาดเล็กลงอย่างมาก ถึงกระนั้น mkdwarfs ก็ เร็วกว่าประมาณ 4 เท่า และสร้างภาพที่ เล็กกว่าอิมเมจ SquashFS ถึง 12 เท่า อิมเมจ DwarFS มีขนาดเพียง 0.6% ของขนาดไฟล์ต้นฉบับ
ดังนั้นทำไมไม่ใช้ lzma แทน zstd เป็นค่าเริ่มต้นล่ะ เหตุผลก็คือ lzma นั้นเกี่ยวกับลำดับความสำคัญที่ช้ากว่าในการขยายขนาดมากกว่า zstd หากคุณเข้าถึงข้อมูลบนระบบไฟล์บีบอัดของคุณเป็นครั้งคราว อาจไม่ใช่เรื่องใหญ่ แต่ถ้าคุณใช้มันอย่างกว้างขวาง zstd จะทำให้ประสิทธิภาพดีขึ้น
การเปรียบเทียบข้างต้นไม่ยุติธรรมอย่างสมบูรณ์ mksquashfs โดยค่าเริ่มต้นจะใช้ขนาดบล็อก 128KiB ในขณะที่ mkdwarfs ใช้บล็อก 16MiB เป็นค่าเริ่มต้น หรือแม้แต่ 64MiB บล็อกด้วย -l9 เมื่อใช้ขนาดบล็อกที่เหมือนกันสำหรับทั้งสองระบบไฟล์ ความแตกต่างที่คาดไว้ค่อนข้างจะน่าทึ่งน้อยลงมาก:
$ time mksquashfs install perl-install-lzma-1M.squashfs -comp lzma -b 1M
real 15m43.319s
user 139m24.533s
sys 0m45.132s
$ time mkdwarfs -i install -o perl-install-lzma-1M.dwarfs -l9 -S20 -B3
real 4m25.973s
user 52m15.100s
sys 7m41.889s
$ ll perl-install*.*fs
-rw-r--r-- 1 mhx users 935953866 Mar 13 12:12 perl-install-lzma-1M.dwarfs
-rw-r--r-- 1 mhx users 3407474688 Mar 3 21:54 perl-install-lzma-1M.squashfs
แม้ว่านี่จะ ยัง ไม่ยุติธรรมเลย เนื่องจากมันใช้คุณสมบัติ ( -B3 ) ที่ช่วยให้ DwarFS สามารถอ้างอิงกลุ่มไฟล์จากบล็อกระบบไฟล์ก่อนหน้าสูงสุดสองบล็อก
แต่ประเด็นก็คือนี่คือจุดที่ SquashFS โดดเด่น เนื่องจากไม่รองรับขนาดบล็อกที่ใหญ่กว่าหรือการอ้างอิงด้านหลัง และดังที่คุณจะเห็นด้านล่าง บล็อกขนาดใหญ่ที่ DwarFS ใช้เป็นค่าเริ่มต้นไม่จำเป็นต้องส่งผลเสียต่อประสิทธิภาพการทำงาน
DwarFS ยังมีตัวเลือกในการบีบอัดระบบไฟล์ที่มีอยู่ใหม่ด้วยอัลกอริธึมการบีบอัดที่แตกต่างกัน สิ่งนี้มีประโยชน์เนื่องจากช่วยให้สามารถทดลองอัลกอริธึมและตัวเลือกต่างๆ ได้อย่างรวดเร็วโดยไม่จำเป็นต้องสร้างระบบไฟล์ใหม่ทั้งหมด ตัวอย่างเช่น การบีบอัดระบบไฟล์ด้านบนใหม่ด้วยการบีบอัดที่ดีที่สุด ( -l 9 ):
$ time mkdwarfs --recompress -i perl-install.dwarfs -o perl-lzma-re.dwarfs -l9
I 20:28:03.246534 filesystem rewrittenwithout errors [148.3s]
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
filesystem: 4.261 GiB in 273 blocks (0 chunks, 0 inodes)
compressed filesystem: 273/273 blocks/372.7 MiB written
████████████████████████████████████████████████████████████████████▏100%
real 2m28.279s
user 37m8.825s
sys 0m43.256s
