Haruskah saya menggunakan btrfs atau Ext4 untuk SSD saya?


16

Haruskah saya menggunakan btrfs (dengan opsi discard, compress = lzo dan space_cache) atau Ext4 (dengan opsi discard) untuk SSD untuk Ubuntu 11.10 (Oneiric) partisi root desktop amd64 saya dari mesin kantor saya?

/ home akan menjadi HDD sehingga keandalan fs mempengaruhi OS bukan data saya.

Jawaban:


13

Menurut tes oleh phoronix itu selalu tergantung pada banyak faktor. Dalam satu kasus Btrfsakan jauh lebih baik daripada EXT4saat membaca file besar pada SSD. Demikian pula saat mempertimbangkan kinerja transaksi Disk, Ext4dapat melakukan yang lebih baik daripada nanti.

Anda dapat melihat melalui tes ini di sini , di sini dan di sini (PERINGATAN: Artikel yang panjang).

Tetapi secara keseluruhan, Btrfs sekarang tidak memiliki keunggulan kinerja kuantitatif atas sistem file EXT4 , Bahkan ketika menggunakan dalam mode SSD.

Jadi Anda dapat memilih dari Ext4sekarang.


2
Artikel-artikelnya adalah Sep 2011, 9 Agustus 2010 dan 29 Mei 2009. Berfokus pada yang terbaru karena saya berasumsi btrf akan berkembang selama 2 tahun terakhir. Grafik btrfs + LZO pada halaman 4 luar biasa untuk kinerja membaca dan menulis berurutan, tetapi btrfs buruk dengan penulisan acak sehingga jelas tidak untuk btrfs untuk gambar DBs dan VM. Saya kira dengan partisi root, sebagian besar pembacaan acak, yang tidak jauh lebih baik daripada ext4.
Graham

Dalam beberapa tahun Btrfs akan berubah menjadi opsi yang lebih baik daripada EXT4. Ini sistem file yang lebih menjanjikan :)
NBK

7

Bagi mereka yang tersandung pada pertanyaan ini pada tahun 2016 ... Gunakan ext4. Saya mencoba btrfs dan perbedaannya sangat besar. Selama 10 hari menulis IO ke ext4 berjumlah 17.800 sektor. Btrfs? 490.400 sektor. SSD yang sama, sistem file yang identik, partisi yang berbeda. Pada dasarnya, beban kerja yang sama.

Baik ext4 dan btrfs "sunyi" ketika tidak ada aktivitas tulis pada drive. Itu bagus.

Ext4 akan menulis data yang dimodifikasi, ditambah beberapa overhead. Overhead berhubungan dengan data yang ditulis. Tulisan 4K (1 blok) mendorong sekitar 50-80 blok overhead pada komit berikutnya. (Jurnal ext4 diaktifkan sepenuhnya)

Ubah satu blok 4K pada btrfs dan Anda akan mendorong antara 4000-5000 blok overhead pada komit berikutnya. Komit default adalah 30 detik, saya percaya. Saya menggunakan 120.

Sekarang, itu tergantung pada bagaimana Anda menggunakan SSD. Sebagai root, biasanya ada aliran menulis yang cukup konstan, tingkat rendah, yang terjadi. Log file, file drift ntp, rekondisi man db, pembaruan topologi opensm, dll, dll. Setiap peristiwa akan memalu drive btrfs dengan 4000-5000 penulisan.

Angka 10 hari di atas adalah untuk SSD "tulis terbatas" saya. Sebagian besar dari 17.800 sektor tersebut adalah hasil dari pembaruan sistem yang lebih kecil. Satu salinan btrf tidak menderita. Penulis saya, tepatnya, ntp drift, topologi opensm, dan pembaruan man db (nightly). Tidak ada yang lain yang mengenai disk itu, kecuali hal-hal yang dimulai secara aktif seperti peningkatan sistem vim /etc/whatever, dll

Secara keseluruhan SSD akan menderita banyak penulisan, sungguh. Aku hanya tidak bisa melihat gunanya memboroskan mereka hanya karena media berita mengejar kelinci dan pelangi. Jika Anda ingin membayar harga ini untuk KK, lakukan saja. Untuk "kinerja", tidak terlalu banyak. Ini adalah SSD dan Anda mungkin bisa menempatkan "sistem file" terburuk yang diketahui oleh manusia, dan masih mendapatkan beberapa tingkat kinerja - hanya dengan kekuatan kasar. Ext4, sejauh ini, bukan sistem file terburuk yang diketahui manusia.

Tidak ada pemeriksaan fs bulanan. Coba skrip di bawah ini. Ini adalah hack 100%, tidak akan berfungsi untuk 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

Ini akan memberi tahu Anda berapa banyak blok yang ditulis, sesuai dengan drive itu sendiri, dan file mana yang diperbarui. Membutuhkan root privs. Lihat diri mu sendiri. Saya menjalankan SSD pada sistem file root, dan memanggil script stat.sh. Begitu...sudo ./stat.sh /


Saya tidak suka metode perbandingan Anda. Misalnya, pemeriksaan fs bulanan dimulai dan Anda mendapatkan hasil itu. Btrf adalah default hampir di mana-mana sekarang, dan untuk alasan yang bagus.
Barafu Albino

Tidak ada pemeriksaan fs bulanan. Coba skrip di bawah ini. Ini adalah hack 100%, tidak akan berfungsi untuk mountpoint md, dll ...
wkirk

2
Mengapa overhead menulis begitu besar? Anda menyatakan, bahwa 1 blok menciptakan 50-80 blok yang ditulis bahkan pada ext4 - yaitu 40 kali lebih banyak dari yang dibutuhkan. Mengapa?
Golar Ramblar

saya mempertanyakan apakah ini masih benar pada akhir 2018. dalam pengujian saya, saya membandingkan jumlah yang ditulis menurut iotop dan smartctl dan menemukan yang terakhir mengklaim 3x jumlah sebagai yang sebelumnya (ext4).
Michael

2

Terakhir kali saya mengujinya, dan saya belum pernah mendengar yang berbeda dari mana pun, ext4 memakan media solid-state. (thumbdrives, solid-state drive, dll.) Saya tidak merekomendasikan menggunakannya pada perangkat seperti itu. Gunakan ext3 sebagai gantinya. Untuk sebagian besar kasus pada SSD, Anda tidak akan dapat membedakannya.

BTRFS belum cukup stabil. Namun, ini cukup stabil untuk aplikasi yang tidak kritis. Ini yang saya gunakan untuk membuat flash drive yang dapat di-boot. Jika Anda menggunakan kompres = zlib dan ssd sebagai opsi pemasangan Anda, kompresi akan menggantikan kecepatan tulis yang lebih rendah dari sebagian besar media solid-state dan ssd mengubah algoritme alokasi menjadi yang berkinerja lebih baik secara signifikan pada perangkat tersebut dan akan menebus setiap level-keausan yang buruk oleh perangkat keras. Satu-satunya area kinerja yang masih menjadi masalah adalah bahwa panggilan sinkronisasi lambat. Ini bukan masalah untuk penggunaan umum, tetapi dpkg panggilan disinkronkan setelah setiap operasi, jadi menginstal dan memperbarui perangkat lunak bisa lambat. BTRFS juga menawarkan snapshotting dan fitur-fitur canggih lainnya yang cukup berguna dalam keadaan tertentu.

Jika Anda memutuskan untuk menggunakan BTRFS, pastikan untuk menggunakan distro menggunakan kernel 3.2.0-2 atau yang lebih baru. 3.1.x bisa diterapkan jika perlu. Untuk kernel yang lebih tua, Anda harus mengkompilasi sendiri modul BTRFS terbaru. Yang built-in hampir stabil, tetapi koreksi kesalahan tidak berfungsi di versi yang lebih lama, yang dapat membuat Anda menjadi anak sungai jika terjadi kesalahan. Versi terbaru memiliki fsck yang sebenarnya dapat memperbaiki kesalahan yang paling umum.

Satu peringatan terakhir, saya telah mendengar laporan bahwa swapfile pada sistem file BTRFS akan merusaknya. Masalah ini mungkin telah diperbaiki, tetapi pastikan untuk memeriksa dengan cermat sebelum menerapkannya.

Jika Anda memerlukan bantuan untuk menyiapkan pengaturan BTRFS seperti yang Anda inginkan, beri tahu saya. Saya telah melakukan beberapa yang gila yang bekerja dengan cukup baik untuk hal-hal tertentu.


2

Saya tidak akan menggunakan ext4 pada solid state drive berdasarkan bukti anekdotal dan pengalaman saya sendiri yang menunjukkan ext4 dapat sangat mengurangi masa pakai SSD karena jumlah membaca dan menulis yang terkait dengan sistem file. Satu artikel yang baru-baru ini saya baca menyarankan agar ext4 yang tidak dioptimalkan (akuntansi untuk ukuran halaman, dll.) Pada SSD dapat mengurangi masa pakai disk menjadi setengahnya. Setelah seminggu melakukan pemecahan masalah, saya sampai pada kesimpulan bahwa SSD saya sendiri hanya bertahan selama delapan bulan karena masalah ini. Jika Anda menggunakan SSD, lakukan banyak membaca tentang cara mengoptimalkan sistem file berdasarkan hal-hal seperti ukuran halaman flash yang mungkin berbeda dari ukuran silinder khas yang diatur oleh sistem file.


2
Bisakah Anda memberikan tautan ke, atau informasi identitas lainnya untuk, artikel yang Anda baca?
Eliah Kagan

Saya akan mencoba mencari artikel itu secara khusus. Harap diingat, pernyataan itu ditemukan di internet saat berselancar di toko cerutu. Garis Dasar, lakukan bacaan dan pekerjaan rumah Anda sebelum menggunakan ext4 pada SSD. Lihatlah artikel tentang hal-hal seperti TRIMM dan optimisasi. Apa pun yang Anda lakukan, jangan seperti saya dan mulai mendapatkan kesalahan I / O pada perintah seperti "sudo reboot" setelah delapan bulan.
user75153
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.