ฉันควรใช้ btrfs (พร้อมตัวเลือกการบีบอัด = lzo และ space_cache) หรือ Ext4 (พร้อมตัวเลือกการทิ้ง) สำหรับ SSD สำหรับ Ubuntu 11.10 (Oneiric) amd64 บนเดสก์ทอปพาร์ทิชันรูทของเครื่องทำงาน
/ home จะเป็น HDD ดังนั้น fs จึงมีผลต่อความน่าเชื่อถือของระบบปฏิบัติการไม่ใช่ข้อมูลของฉัน
คำตอบ:
ตามการทดสอบโดยphoronixมันขึ้นอยู่กับหลายปัจจัยเสมอ ในกรณีหนึ่งBtrfsจะทำได้ดีกว่าEXT4เมื่ออ่านไฟล์ขนาดใหญ่บน SSD ในขณะเดียวกันเมื่อพิจารณาประสิทธิภาพของธุรกรรมดิสก์Ext4สามารถทำงานได้ดีกว่าในภายหลัง
คุณสามารถดูได้ผ่านการทดสอบเหล่านี้ที่นี่ , ที่นี่และที่นี่ (คำเตือน: บทความยาว)
แต่เมื่อรวมกันแล้วBtrfs ในตอนนี้ไม่มีข้อได้เปรียบด้านประสิทธิภาพเชิงปริมาณเหนือระบบไฟล์ EXT4แม้ว่าจะใช้ในโหมด SSD ก็ตาม
ดังนั้นคุณสามารถเลือกได้ในExt4ตอนนี้
สำหรับผู้ที่สะดุดในคำถามนี้ในปี 2016 ... ใช้ ext4 ฉันลอง btrfs และความแตกต่างนั้นมีนัยสำคัญ ระยะเวลา 10 วันในการเขียน IOs ไปยัง ext4 มีจำนวน 17,800 เซกเตอร์ Btrfs? ภาค 490,400 SSD เดียวกันระบบไฟล์ที่เหมือนกันพาร์ติชันที่แตกต่างกัน โดยทั่วไปปริมาณงานเดียวกัน
ทั้ง ext4 และ btrfs ไป "เงียบ" เมื่อไม่มีกิจกรรมการเขียนบนไดรฟ์ ดีแล้ว.
Ext4 จะเขียนข้อมูลที่แก้ไขรวมทั้งค่าใช้จ่าย ค่าโสหุ้ยเกี่ยวข้องกับข้อมูลที่เขียน การเขียนขนาด 4K (1 บล็อก) จะเพิ่มค่าใช้จ่ายประมาณ 50-80 บล็อกในการส่งครั้งถัดไป (ext4 Journal เปิดใช้งานอย่างสมบูรณ์)
ปรับเปลี่ยนบล็อก 4K หนึ่งบล็อกบน btrfs และคุณจะผลักดันค่าใช้จ่ายระหว่าง 4,000-5,000 บล็อกของค่าใช้จ่ายในการส่งครั้งถัดไป ความมุ่งมั่นเริ่มต้นคือ 30 วินาทีฉันเชื่อ ฉันใช้ 120
ตอนนี้มันขึ้นอยู่กับวิธีที่คุณใช้ SSD ในฐานะที่เป็นรูทมักจะมีระดับคงที่ค่อนข้างต่ำกระแสการเขียนที่เกิดขึ้น ล็อกไฟล์, ไฟล์ดริฟท์ ntp, man db rebuilds, การอัพเดตโทโพโลยี opensm, ฯลฯ ฯลฯ แต่ละเหตุการณ์จะใช้ไดรฟ์ btrfs พร้อมกับการเขียนอีก 4,000-5,000 รายการ
หมายเลข 10 วันข้างต้นใช้สำหรับ "จำกัด การเขียน" ของฉัน ส่วนใหญ่ของภาค 17,800 นั้นเป็นผลมาจากการปรับปรุงระบบขนาดเล็ก หนึ่งสำเนา btrfs ไม่ประสบ นักเขียนของฉันคือ ntp drift, opensm topology และ man db updates (nightly) ไม่มีสิ่งใดที่กระทบกับดิสก์นั้นยกเว้นสิ่งที่เริ่มต้นอย่างแข็งขันเช่นการอัพเกรดระบบvim /etc/whateverฯลฯ
สำหรับ SSD ทั้งหมดนั้นจะมีงานเขียนจำนวนมากจริงๆ ฉันไม่สามารถเห็นจุดที่ทำให้พวกเขาสูญเสียเพียงเพราะสื่อมวลชนกำลังไล่ล่ากระต่ายและสายรุ้ง หากคุณต้องการจ่ายราคานี้สำหรับ COW ไปเลย สำหรับ "ประสิทธิภาพ" ไม่มาก มันเป็น SSD และคุณอาจใส่ "ระบบไฟล์" ที่เลวร้ายที่สุดที่คนรู้จักบนมันและยังคงได้ประสิทธิภาพในระดับหนึ่ง - เพียงแค่กำลังดุร้าย Ext4 คือระบบไฟล์ที่แย่ที่สุดที่มนุษย์รู้จัก
ไม่มีการตรวจสอบ fs รายเดือน ลองใช้สคริปต์ด้านล่าง มันเป็นการแฮ็ค 100% จะไม่ทำงานสำหรับ md mountpoints
#! /bin/bash
dev=`cat /proc/mounts | grep " $1 " | awk '{print $1}'`
x=`basename $dev`
vmnam=`lsblk $dev -o MOUNTPOINT,PKNAME | grep "$1" | awk '{print $2}'`
vmx=`vmstat -d | grep $vmnam | awk '{print $8}'`
lbax=`smartctl -a $dev | grep LBA | awk '{print $10}'`
tmpnam=`mktemp XXX`
echo "Tracking device: $dev, mounted on $1 (vmstat on $vmnam)"
tim=`date +%s`
timx=`date +%s`
while true
do
vm=`vmstat -d | grep "$vmnam" | awk '{print $8}'`
lba=`smartctl -a $dev | grep LBA | awk '{print $10}'`
if [ "$vm" != "$vmx" ]
then
tim=`date +%s`
dif=`dc <<< "$vm $vmx - p"`
lbad=`dc <<< "$lba $lbax - p"`
timd=`dc <<< "$tim $timx - p"`
echo `date` " (sec=$timd) writes=$vm (dif=$dif) (lba=$lbad)"
vmx="$vm"
lbax="$lba"
timx="$tim"
find "$1" -mount -newer "$tmpnam" -print | grep -v "/tmp"
touch "$tmpnam"
fi
sleep 1
doneมันจะบอกคุณว่ามีกี่บล็อกที่ถูกเขียนตามตัวไดรฟ์และไฟล์ที่ถูกอัพเดต ต้องการสิทธิ์รูท ดูด้วยตัวคุณเอง ฉันเรียกใช้ SSD บนระบบไฟล์รูทและเรียกใช้สคริปต์ stat.sh ดังนั้น...sudo ./stat.sh /
ครั้งสุดท้ายที่ฉันทดสอบมันและฉันยังไม่เคยได้ยินที่แตกต่างกันไปทุกที่ ext4 กินสื่อโซลิดสเตต (thumbdrives ไดรฟ์โซลิดสเตต ฯลฯ ) ฉันไม่แนะนำให้ใช้กับอุปกรณ์ดังกล่าว ใช้ ext3 แทน สำหรับกรณีส่วนใหญ่บน SSD คุณจะไม่สามารถบอกความแตกต่างได้
BTRFS นั้นยังค่อนข้างมีเสถียรภาพ อย่างไรก็ตามมันมีความเสถียรเพียงพอสำหรับการใช้งานที่ไม่สำคัญ มันเป็นสิ่งที่ฉันใช้สำหรับการทำแฟลชไดรฟ์ที่สามารถบู๊ตได้ หากคุณใช้ compress = zlib และ ssd เป็นตัวเลือกการเมานต์การบีบอัดจะทำขึ้นสำหรับความเร็วในการเขียนที่ลดลงของสื่อโซลิดสเตทส่วนใหญ่และ ssd จะเปลี่ยนอัลกอริทึมการจัดสรรเป็นหนึ่งที่ทำงานได้ดีกว่า การปรับระดับการสึกหรอต่ำโดยฮาร์ดแวร์ พื้นที่ประสิทธิภาพเดียวที่ยังคงมีปัญหาคือการเรียกการซิงค์ช้า นี่ไม่ใช่ปัญหาสำหรับการใช้งานทั่วไป แต่สาย dpkg จะซิงค์หลังจากการทำงานทุกครั้งดังนั้นการติดตั้งและอัปเดตซอฟต์แวร์อาจช้า BTRFS ยังนำเสนอภาพรวมและคุณสมบัติขั้นสูงอื่น ๆ ที่ค่อนข้างมีประโยชน์ภายใต้สถานการณ์บางอย่าง
หากคุณตัดสินใจที่จะใช้ BTRFS โปรดใช้ distro โดยใช้เคอร์เนล 3.2.0-2 หรือใหม่กว่า 3.1.x สามารถใช้งานได้หากจำเป็น สำหรับเมล็ดเก่าคุณจะต้องรวบรวมโมดูล BTRFS ล่าสุดด้วยตัวคุณเอง ตัวที่สร้างขึ้นเกือบจะเสถียร แต่การแก้ไขข้อผิดพลาดไม่ทำงานในเวอร์ชั่นที่เก่ากว่าซึ่งอาจทำให้คุณลำห้วยหากมีบางอย่างผิดปกติ เวอร์ชันล่าสุดมี fsck ที่สามารถซ่อมแซมข้อบกพร่องที่พบบ่อยที่สุดได้
ข้อแม้สุดท้ายที่ฉันได้ยินรายงานว่า swapfiles ในระบบไฟล์ BTRFS จะเสียหาย ปัญหานี้อาจได้รับการแก้ไขแล้ว แต่ต้องตรวจสอบให้ดีก่อนดำเนินการ
หากคุณต้องการความช่วยเหลือใด ๆ ในการตั้งค่า BTRFS ตามที่คุณต้องการโปรดแจ้งให้เราทราบ ฉันได้ทำหุ่นบ้าสองตัวที่ใช้งานได้ดีกับสิ่งที่เฉพาะเจาะจง
ฉันจะไม่ใช้ ext4 กับไดรฟ์โซลิดสเตตจากหลักฐานประวัติและประสบการณ์ของฉันที่แนะนำ ext4 สามารถลดอายุการใช้งานของ SSD ได้อย่างมากเนื่องจากจำนวนการอ่านและเขียนที่เกี่ยวข้องกับระบบไฟล์ หนึ่งบทความที่ฉันเพิ่งอ่านแนะนำว่า unoptimized (การบัญชีสำหรับขนาดหน้า ฯลฯ ) ext4 บน SSD สามารถลดอายุการใช้งานของดิสก์ครึ่ง หลังจากหนึ่งสัปดาห์ของการแก้ไขปัญหาฉันได้ข้อสรุปว่า SSD ของตัวเองใช้เวลาเพียงแปดเดือนเนื่องจากปัญหานี้ หากคุณใช้ SSD ให้อ่านจำนวนมากเกี่ยวกับวิธีปรับแต่งระบบไฟล์ตามสิ่งต่าง ๆ เช่นขนาดหน้าแฟลชซึ่งอาจแตกต่างจากขนาดกระบอกสูบทั่วไปที่ระบบไฟล์ตั้งค่าไว้