Verifikasi dukungan TRIM dengan BtrFS pada SSD


21

Kami sedang mencari untuk menggunakan BtrFS pada array disk SSD dan saya telah diminta untuk memverifikasi bahwa BtrFS sebenarnya melakukan operasi TRIM setelah menghapus file. Sejauh ini saya belum dapat memverifikasi bahwa perintah TRIM dikirim ke disk.

Saya tahu BtrFS tidak dianggap sebagai produksi siap, tetapi kami menyukai tepi perdarahan, oleh karena itu saya mengujinya. Servernya adalah Ubuntu 11.04 server 64-bit rilis (mkfs.btrfs versi 0.19). Saya telah menginstal kernel Linux 3.0.0 karena changelog BtrFS menyatakan bahwa TRIM massal tidak tersedia di kernel yang dikirimkan bersama Ubuntu 11.04 (2.6.38).

Inilah metodologi pengujian saya (awalnya diadopsi dari http://andyduffell.com/techblog/?p=852 , dengan modifikasi agar berfungsi dengan BtrFS):

  • TRIM disk secara manual sebelum memulai: for i in {0..10} ; do let A="$i * 65536" ; hdparm --trim-sector-ranges $A:65535 --please-destroy-my-drive /dev/sda ; done
  • Verifikasi drive itu TRIM'd: ./sectors.pl |grep + | tee sectors-$(date +%s)
  • Mempartisi drive: fdisk /dev/sda
  • Buat sistem file: mkfs.btrfs /dev/sda1
  • Meningkat: sudo mount -t btrfs -o ssd /dev/sda1 /mnt
  • Buat file: dd if=/dev/urandom of=/mnt/testfile bs=1k count=50000 oflag=direct
  • Pastikan file ada di disk: ./sectors.pl | tee sectors-$(date +%s)
  • Hapus file uji: rm /mnt/testfile
  • Lihat bahwa file pengujian TRIM dari disk: ./sectors.pl | tee sectors-$(date +%s)
  • Verifikasi blok TRIM'd: diffdua sectors-*file terbaru

Pada titik ini, verifikasi pra-hapus dan pasca-hapus masih menunjukkan blok-blok disk yang sama sedang digunakan. Saya seharusnya melihat pengurangan jumlah blok yang digunakan. Menunggu satu jam (kalau-kalau perlu waktu agar perintah TRIM dikeluarkan) setelah file uji dihapus masih menunjukkan blok yang sama digunakan.

Saya juga telah mencoba memasang dengan -o ssd,discardopsi - opsi, tetapi itu tampaknya tidak membantu sama sekali.

Partisi yang dibuat dari fdiskatas (saya menjaga partisi kecil agar verifikasi dapat berjalan lebih cepat):

root@ubuntu:~# fdisk -l -u /dev/sda

Disk /dev/sda: 512.1 GB, 512110190592 bytes
255 heads, 63 sectors/track, 62260 cylinders, total 1000215216 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x6bb7542b

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1              63      546209      273073+  83  Linux

sectors.plSkrip saya (saya tahu ini tidak efisien, tetapi menyelesaikan pekerjaan):

#!/usr/bin/perl -w

use strict;

my $device = '/dev/sda';
my $start = 0;
my $limit = 655360;

foreach ($start..$limit) {
    printf "\n%6d ", $_ if !($_ % 50);
    my @sector = `/sbin/hdparm --read-sector $_ $device`;
    my $status = '.';
    foreach my $line (@sector) {
            chomp $line;
            next if $line eq '';
            next if $line =~ /$device/;
            next if $line =~ /^reading sector/;
            if ($line !~ /0000 0000 0000 0000 0000 0000 0000 0000/) {
                    $status = '+';
            }
    }
    print $status;
}
print "\n";

Apakah metodologi pengujian saya cacat? Apakah saya melewatkan sesuatu di sini?

Terima kasih untuk bantuannya.


1
Saya sepenuhnya mendukung pengujian hal-hal yang berdarah, tapi supaya Anda tahu, sampai sekarang, btrfs tidak memiliki fsck yang sebenarnya, Anda tahu, memperbaiki hal-hal: btrfs.wiki.kernel.org/index.php/Main_Page - so hati-hati untuk itu.
Matt Simmons

@ Matt - Poin bagus tentang fsck yang hilang. Pemahaman saya adalah bahwa versi pertama dari fsck akan dikirim dalam beberapa minggu ke depan, jadi kita harus dilindungi pada saat kita memindahkan ini ke produksi. Selain itu, kami akan memiliki beberapa salinan data kami, jadi jika kami kehilangan satu salinan, kami memiliki setidaknya dua salinan lagi untuk dipulihkan. Tapi saya sepenuhnya setuju bahwa ini bukan sistem file untuk orang-orang dengan data yang tak tergantikan untuk saat ini.
Shane Meyers

1
Mungkin tidak akan mengubah apa pun, tetapi Anda sebaiknya mencoba menjalankan syncsetelah rmming file.
zebediah49

Saya ingin mengatakan bahwa saya mencoba menjalankan syncsetelah menghapus file dan hasilnya masih sama. Saya akan mengecek bahwa ketika saya kembali ke kantor setelah akhir pekan berakhir.
Shane Meyers

jika Anda tidak keberatan dengan pendarahan, pernahkah Anda mempertimbangkan zfsonlinux.org ? asli (yaitu di kernel, bukan sekering) ZFS untuk linux. mereka dekat dengan "rilis" resmi, dan memiliki RC yang tersedia (termasuk PPA untuk Ubuntu - cukup mudah untuk membangun kembali untuk debian juga)
cas

Jawaban:


4

Jadi setelah beberapa hari mengerjakan ini, saya bisa menunjukkan bahwa BtrFS memang menggunakan TRIM. Saya tidak berhasil menjalankan TRIM di server tempat kami akan menggunakan SSD ini. Namun, ketika pengujian menggunakan drive yang sama dicolokkan ke laptop, tes berhasil.

Perangkat keras yang digunakan untuk semua pengujian ini:

  • SSD penting m4 512GB
  • HP DL160se G6
  • LSI LSISAS9200-8e HBA
  • kandang SAS generik
  • Laptop Dell XPS m1210

Setelah banyak upaya gagal memverifikasi BtrFS di server, saya memutuskan untuk mencoba tes yang sama menggunakan laptop lama (menghapus lapisan kartu RAID). Upaya awal pengujian ini menggunakan Ext4 dan BtrFS pada laptop gagal (data tidak TRIM).

Saya kemudian memutakhirkan firmware drive SSD dari versi 0001 (seperti dikirim keluar dari kotak) ke versi 0009. Pengujian diulangi dengan Ext4 dan BtrFS dan kedua sistem file berhasil MEMPERPANJANG data.

Untuk memastikan perintah TRIM punya waktu untuk berjalan, saya melakukan rm /mnt/testfile && sync && sleep 120sebelum melakukan validasi.

Satu hal yang perlu diperhatikan jika Anda mencoba tes yang sama: SSD telah menghapus blok tempat mereka beroperasi (saya tidak tahu ukuran blok penghapusan m4 yang penting). Ketika sistem file mengirimkan perintah TRIM ke drive, drive hanya akan menghapus blok lengkap; jika perintah TRIM ditentukan untuk sebagian blok, blok itu tidak akan TRIM karena sisa data yang valid dalam blok hapus.

Jadi untuk menunjukkan apa yang saya bicarakan (output dari sectors.plskrip di atas). Ini dengan file uji pada SSD. Periode adalah sektor yang hanya mengandung nol. Plus memiliki satu atau lebih byte yang bukan nol.

File uji pada drive:

24600 .......................................+++++++++++
24650 ++++++++++++++++++++++++++++++++++++++++++++++++++
24700 ++++++++++++++++++++++++++++++++++++++++++++++++++
    -- cut --
34750 ++++++++++++++++++++++++++++++++++++++++++++++++++
34800 ++++++++++++++++++++++++++++++++++++++++++++++++++
34850 +++++++++++++++++++++++++++++.....................

File uji dihapus dari drive (setelah a sync && sleep 120):

24600 .......................................+..........
24650 ..................................................
24700 ..................................................
    -- cut --
34750 ..................................................
34800 ..................................................
34850 ......................+++++++.....................

Tampaknya sektor pertama dan terakhir dari file berada dalam blok hapus yang berbeda dari sisa file. Karena itu beberapa sektor tidak tersentuh.

Formulir takeaway ini: beberapa instruksi pengujian Ext4 TRIM meminta pengguna untuk hanya memverifikasi bahwa sektor pertama adalah TRIM dari file. Penguji harus melihat sebagian besar file tes untuk benar-benar melihat apakah TRIM berhasil atau tidak.

Sekarang untuk mencari tahu mengapa mengeluarkan perintah TRIM secara manual yang dikirim ke SSD melalui kerja kartu RAID tetapi perintah TRIM otomatis untuk tidak ...


Saya pikir semua HW RAID memakan perintah trim, senang melihat bahwa semuanya perlahan-lahan berubah. Di sisi lain, dengan drive modern yang baik, TRIM semakin tidak berarti.
Ronald Pottol

4

Berdasarkan apa yang saya baca, mungkin ada kesalahan dalam metodologi Anda.

Anda mengasumsikan bahwa TRIM akan menghasilkan SSD Anda dengan mem-blok-blokkan blok-blok yang telah dihapus. Namun hal ini sering tidak terjadi.

Itu hanya jika SSD mengimplementasikan TRIM sehingga nol blok yang dibuang. Anda dapat memeriksa apakah perangkat setidaknya cukup tahu untuk melaporkan discard_zeroes_data:

cat / sys / block / sda / queue / discard_zeroes_data

Juga, bahkan jika SSD tidak nol, mungkin perlu waktu - baik setelah discard selesai - agar SSD benar-benar nol blok (ini berlaku untuk beberapa SSD berkualitas lebih rendah).

http://www.redhat.com/archives/linux-lvm/2011-April/msg00048.html

BTW Saya sedang mencari cara yang dapat diandalkan untuk memverifikasi TRIM dan belum menemukannya. Saya ingin tahu jika ada yang menemukan jalan.


3

Berikut ini adalah metodologi pengujian untuk 10.10 dan EXT4. Mungkin itu akan membantu.

/ubuntu/18903/how-to-enable-trim

Oh dan saya pikir Anda perlu membuang parameter pada fstab mount. Tidak yakin apakah param SSD diperlukan karena saya pikir seharusnya mendeteksi SSD secara otomatis.


2
Saya telah berusaha mengikuti instruksi verifikasi SSD Ext4, tetapi tidak berfungsi karena perbedaan dalam cara BtrFS bekerja dibandingkan dengan sistem file lainnya. Karenanya alur kerja saya datang dengan. Saya menggunakan ssdopsi mount untuk memastikan bahwa BtrFS tahu untuk menggunakan kode spesifik SSDnya meskipun harus dideteksi secara otomatis. Saya juga mencoba menggunakan discard(seperti disebutkan di atas) dan tidak membantu.
Shane Meyers

Baiklah. Layak dicoba :)
Dave Veffer

1

Untuk btrf Anda memerlukan discardopsi untuk mengaktifkan dukungan TRIM.

Tes yang sangat sederhana namun berfungsi untuk TRIM fungsional ada di sini: http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/2


1
Seperti yang saya sebutkan di atas, saya mencoba pengujian saya dengan discardopsi dan ssdopsi. Dokumen BtrFS banyak menyebutkan ssdopsi, jadi saya memfokuskan pengujian saya di sana, tetapi tidak satupun opsi menghasilkan hasil yang saya harapkan. Sebagian besar halaman web yang menunjukkan cara menguji TRIM adalah untuk Ext4 dan sejenisnya. BtrFS tidak dapat diuji menggunakan metodologi tersebut karena perbedaan dalam desain sistem file.
Shane Meyers

hdparm --fibmapadalah FS agnostik. Blok di alamat LBA yang diberikan adalah nol, atau tidak, apakah itu extN, btrfs, xfs, jfs ... ssdopsi tidak relevan untuk trim, lihat misalnya diskusi tentang milis btrf ini : mail-archive.com/linux-btrfs @ vger.kernel.org / msg10932.html .
Paweł Brodacki

Saya mencoba menggunakan hdparm --fibmaptetapi tidak berhasil pada BtrFS. Jika Anda melihat README wiper.sh (didistribusikan bersama hdparm), mereka secara eksplisit menyatakan bahwa "FIEMAP / FIBMAP ioctl () panggilan benar-benar tidak aman ketika digunakan pada sistem file btrfs." Jadi hdparm keluar, yang terlalu buruk karena ini akan membuat pengujian berjalan lebih mudah. Saya tidak tahu bahwa ssdopsi tidak ada hubungannya dengan TRIM karena dokumen tidak begitu jelas tentang kegunaan opsi.
Shane Meyers

Terima kasih atas informasi tambahan tentang ioctls, saya tidak mengetahuinya. Saya pikir tempat terbaik untuk meminta informasi tambahan adalah milis btrfs. Anda akan mendapatkan informasi langsung dari sana.
Paweł Brodacki

1

Beberapa hal yang perlu dipikirkan (untuk membantu menjawab pertanyaan "apakah saya kehilangan sesuatu?"):

  • apa sebenarnya / dev / sda? satu SSD? atau (hardware?) RAID array SSD?

  • jika yang terakhir maka apa jenis RAID controller?

  • dan apakah pengontrol serangan Anda mendukung TRIM?

dan akhirnya,

  • apakah metode pengujian Anda memberi Anda hasil yang Anda harapkan jika Anda memformat / dev / sda1 dengan sesuatu selain btrfs?

1

Hampir semua SSD dengan antarmuka SATA menjalankan semacam sistem file struktur log yang benar-benar tersembunyi dari Anda. Perintah 'trim' SATA memberi tahu perangkat bahwa blok tidak lagi digunakan dan bahwa filesystem struktur log yang mendasarinya dapat mem-flashnya / jika / blok hapus yang sesuai (yang mungkin jauh lebih besar) / hanya / berisi blok yang ditandai dengan trim.

Saya belum membaca dokumen standar, yang ada di sini: http://t13.org/Documents/MinutesDefault.aspx?keyword=trim , tapi saya tidak yakin apakah ada jaminan tingkat standar yang dapat Anda lakukan lihat hasil dari perintah trim. Jika Anda dapat melihat sesuatu berubah, seperti beberapa byte pertama yang nol pada awal blok hapus, saya tidak berpikir ada jaminan ini berlaku di perangkat yang berbeda atau bahkan mungkin versi firmware.

Jika Anda berpikir tentang cara abstraksi diimplementasikan, seharusnya dimungkinkan untuk membuat hasil dari perintah trim benar-benar tidak terlihat oleh yang baru saja membaca / menulis blok. Lebih jauh lagi mungkin sulit untuk mengetahui blok mana yang berada dalam blok hapus yang sama, karena hanya layer terjemahan flash yang tahu itu dan mungkin telah menyusunnya kembali secara logis.

Mungkin ada perintah SATA (perintah OEM mungkin?) Untuk mengambil metadata yang terkait dengan lapisan terjemahan flash SSD?

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.